企业官网建设流程全解析

毫米波雷达在自动驾驶感知栈里一直是个尴尬角色：点云稀疏、噪声大、标注成本高，很多做视觉的同行拿到 nuScenes 之后，摄像头和激光雷达玩得飞起，雷达那部分数据却常年躺在文件夹里吃灰。我最初也是这样，直到有一次做恶劣天气下的感知冗余验证，才发现雷达数据的价值被严重低估了。nuScenes 是目前少有的、把毫米波雷达原始数据完整开源出来的大规模数据集，它给的不是那种已经处理好的目标级轨迹，而是每一帧、每个雷达传感器的原始点云和速度信息。这意味着你可以拿它做点云级的研究，而不是只能做后融合。这篇内容就是把我这段时间折腾 nuScenes 雷达数据的完整过程整理出来，从数据组织结构、坐标系变换、点云解析，到速度补偿、多雷达融合、可视化验证，一步步讲清楚。适合已经跑通过 nuScenes 基础 devkit、想深入雷达模态的算法工程师和研究生，也适合刚接触自动驾驶多传感器融合、想找一个靠谱数据集练手的同学。下面所有操作都基于官方 devkit 的常见用法，参数和代码我会尽量给全，你照着抄基本能跑通。

1. nuScenes 雷达数据的整体结构与设计逻辑

1.1 为什么 nuScenes 的雷达数据值得单独研究

先说说这个数据集在雷达模态上的定位。nuScenes 采集车顶部有一个旋转式激光雷达，车身四周布置了五个毫米波雷达，分别覆盖前向、左侧、右侧、后向等区域。每个雷达工作在同一频段，输出的是原始检测点，每个点包含距离、方位角、径向速度、雷达截面积等属性。和激光雷达相比，雷达点云在数量上少了两三个数量级，一帧可能只有几十到几百个点，但每个点都带有径向速度，这是激光雷达给不了的。

这个速度信息是雷达的核心价值。激光雷达能告诉你障碍物在哪，但很难直接告诉你它相对你运动多快；雷达通过多普勒效应直接测出径向速度，对运动目标的判别非常敏感。nuScenes 把这份原始数据保留下来，而不是只给目标级结果，这就让做点云级融合、做速度估计、做动态目标分割的人有了发挥空间。我个人的判断是，如果你的研究方向涉及运动补偿、多普勒辅助跟踪、或者恶劣天气下的感知鲁棒性，nuScenes 的雷达数据是绕不开的。

另一个设计上的考量是时间同步。nuScenes 的雷达、激光雷达、摄像头都做了时间戳对齐，每个 sample 对应一个关键帧，sample_data 里记录了各传感器在该时刻的原始数据。雷达的采样频率和激光雷达不完全一致，但 devkit 通过 sample_annotation 和 sample_data 的关联，让你能拿到近似同一时刻的多模态数据。这个对齐精度对融合算法来说够用，但如果你要做严格的逐点时间补偿，就得自己处理时间戳差异，后面我会专门讲。

1.2 数据目录与关键表结构拆解

拿到 nuScenes 数据集后，目录结构大概是这样的：根目录下有 samples、sweeps、maps、v1.0-trainval 等文件夹。雷达数据主要分布在 samples 和 sweeps 里。samples 存的是关键帧，每个关键帧对应一个标注时刻；sweeps 存的是关键帧之间的中间帧，没有标注，但数据量更大，适合做时序研究。

雷达相关的表主要有几张。sensor 表记录了传感器类型和对应的通道，雷达通道通常命名为 RADAR_FRONT、RADAR_FRONT_LEFT、RADAR_FRONT_RIGHT、RADAR_BACK_LEFT、RADAR_BACK_RIGHT 这种。calibrated_sensor 表存的是每个传感器相对于车体坐标系的标定参数，包括平移和旋转四元数。ego_pose 表记录的是车体在全球坐标系下的位姿。sample_data 表把时间戳、文件路径、标定 token、位姿 token 串起来，这是你读取雷达点云的主入口。

我建议你先把这几张表的关系理清楚，不然读点云的时候很容易在坐标系上绕晕。简单说，一个雷达点从原始文件读出来，是在雷达自身坐标系下的；要转到车体坐标系，用 calibrated_sensor 的外参；要转到全球坐标系，再乘上 ego_pose。这个链条和激光雷达完全一致，devkit 里也有现成的函数，但雷达多了一层速度补偿的问题，这是它特殊的地方。

1.3 雷达点云文件格式与字段含义

nuScenes 的雷达点云以 pcd 格式存储，但和常见的激光雷达 pcd 不太一样。它用的是二进制压缩格式，每个点包含五个维度：x、y、z、径向速度、雷达截面积。注意这里的 x、y、z 是雷达坐标系下的空间坐标，单位是米；径向速度单位是米每秒，正负号表示朝向或远离雷达；雷达截面积是一个反映目标反射强度的量，单位是平方米分贝，实际用的时候一般当强度特征处理。

这里有个坑我踩过：不同版本的 devkit 对 pcd 字段的解析方式略有差异，有的版本把速度放在第四个字段，有的把 rcs 放在前面。你读出来之后最好先打印几个点看看数值范围，速度一般在正负几十米每秒以内，rcs 通常在负几十到正几十之间。如果发现数值离谱，多半是字段顺序搞错了。另外，雷达点云里会有不少无效点或者噪声点，官方没有做过滤，需要你自己根据 rcs 阈值或者距离范围做清洗。

2. 雷达点云读取与坐标系变换的核心操作

2.1 用 devkit 读取单帧雷达点云

最省事的方式是用官方 devkit 的 RadarPointCloud 类。它封装了 pcd 解析逻辑，你只要传入文件路径就能拿到点云数组。典型流程是：先初始化 NuScenes 对象，指定 dataroot 和 version；然后拿到某个 sample；从 sample 里取对应雷达通道的 sample_data；再用 RadarPointCloud.from_file 读取。

读出来之后，点云是一个 N 行 5 列的数组。我一般会先做一步有效性过滤，把 rcs 过低或者距离过远的点去掉。实测下来，rcs 阈值设在负二十左右能滤掉大部分杂波，同时保留真实目标。距离方面，前向雷达有效探测距离可以放到两百米，侧向雷达一百米左右比较稳妥。这个阈值不是死的，你要根据自己任务调，做远距离检测就放宽，做近距离高精度就收紧。

读取的时候还要注意 sample 和 sample_data 的区别。一个 sample 对应一个时刻，但同一时刻可能有多个雷达通道的数据，你要遍历 sample 里的雷达通道列表，逐个读取。如果你只读了一个通道，那只是五分之一的数据，融合的时候会缺一大块视野。

2.2 从雷达到车体再到全球的坐标变换

坐标系变换是雷达数据处理里最容易出错的地方。原始点云在雷达坐标系下，雷达安装在车身上有固定的外参，车体又在全球坐标系下运动。完整的变换链是：雷达坐标 → 车体坐标 → 全球坐标。devkit 提供了 get_sample_data 和相关的位姿接口，但雷达的变换和激光雷达有个细节差异。

激光雷达通常只有一个，标定参数固定；雷达有五个，每个的外参都不一样，而且安装角度有偏。前向雷达一般朝向车头，侧向雷达有几十度的偏转。你在做变换的时候，必须用对应通道的 calibrated_sensor，不能混用。我见过有人图省事，所有雷达都用同一个外参，结果点云叠在一起完全对不上，排查了半天才发现是标定用错了。

变换的数学操作就是旋转加平移。旋转用四元数转旋转矩阵，平移直接加。devkit 里有 quaternion 相关的工具函数，你也可以用 scipy 的 Rotation 模块。我习惯用 scipy，因为接口更直观。变换完之后，所有雷达点就统一到车体坐标系或者全球坐标系了，这时候才能做多雷达融合或者和激光雷达对齐。

2.3 速度补偿：雷达特有的处理环节

速度补偿是雷达数据区别于激光雷达的关键操作。雷达测的是径向速度，也就是目标相对雷达沿视线方向的速度分量。但车体本身在运动，所以这个径向速度里混入了自车运动的影响。如果你直接拿原始径向速度做动态目标判断，自车速度会污染结果。

补偿的思路是：先根据自车位姿变化算出车体在全球坐标系下的速度矢量，再把这个速度投影到每个雷达点的视线方向上，从原始径向速度里减掉。这样剩下的就是目标相对地面的真实径向速度。具体实现上，你需要相邻两帧的 ego_pose，做差分得到自车速度，然后对每个雷达点，用它的空间坐标算出视线单位向量，做点积。

这个操作听起来简单，但有几个细节要注意。一是时间间隔要用真实时间戳差，不能用帧号差，因为雷达采样不均匀。二是自车速度最好做平滑，单帧差分噪声大，可以用前后几帧做滑动平均。三是投影的时候要用雷达坐标系下的视线方向，不是车体坐标系，因为径向速度是在雷达坐标系下测的。这几点搞错任何一个，补偿结果都会偏。

3. 多雷达融合与点云增强实操

3.1 五路雷达点云的合并策略

nuScenes 的五个雷达覆盖不同区域，合并之后能得到接近三百六十度的点云覆盖。合并的基本操作是把每个雷达的点云都变换到统一坐标系，然后拼接。但直接拼接会有问题：相邻雷达覆盖区域有重叠，重叠区的点会重复；不同雷达的标定误差会导致同一目标在不同雷达里位置略有偏差。

我的做法是分两步。第一步先做粗合并，把所有雷达点变换到车体坐标系后拼在一起，看看整体覆盖情况。第二步做重叠区处理，对距离很近的点做聚类或者非极大值抑制，保留 rcs 较强的那个。实测下来，前向和侧向雷达在车头两侧有重叠，后向和侧向在车尾两侧有重叠，这些区域如果不处理，点云密度会异常高，影响后续聚类。

合并的时候还要注意时间戳。五个雷达不是严格同时采样的，理论上应该做运动补偿后再合并。但 nuScenes 的雷达时间差通常在几十毫秒以内，低速场景下影响不大，高速场景下就得考虑。如果你做的是高速场景，建议按时间戳对每个雷达点做位姿插值补偿，再合并。

3.2 雷达与激光雷达的点云对齐验证

验证雷达处理是否正确，最直接的办法是和激光雷达点云对齐看。把雷达点变换到激光雷达坐标系，叠加显示，如果雷达点大致落在激光雷达点云描述的物体表面上，说明变换链没问题。如果整体偏移，多半是外参或者坐标系搞错了；如果部分偏移，可能是时间同步或者速度补偿的问题。

我一般会挑几个典型场景做验证：静止的建筑物墙面、行驶中的车辆、路边的护栏。建筑物墙面是静止的，雷达点应该和激光雷达墙面重合；行驶车辆有速度，雷达点可能因为多普勒和运动补偿有轻微偏移，但位置应该对得上；护栏这种细长物体，雷达点会比较稀疏，但分布趋势应该一致。这几个场景过一遍，基本能确认处理流程正确。

对齐的时候有个技巧：先把雷达点云按 rcs 着色，激光雷达按高度着色，这样叠加显示时能区分两种来源。如果雷达点集中在激光雷达物体的边缘或者表面，说明对齐良好；如果雷达点飘在物体外面，就要查变换参数了。

3.3 点云增强与动态目标提取

雷达点云稀疏，直接做检测效果有限，但结合速度信息可以做动态目标提取，这是雷达的强项。思路是：先做速度补偿，得到目标真实径向速度；然后设定速度阈值，把径向速度超过阈值的点标为动态候选；再对动态候选做聚类，得到运动目标簇。

这个流程里，速度阈值的选择很关键。太低会把噪声和静止物体的测量误差误判为动态，太高会漏掉慢速目标。我的经验是，城市场景下阈值设在每秒一米左右比较合适，高速场景可以放到每秒两米。另外，聚类的时候要用自适应带宽，因为雷达点在距离近时密集、距离远时稀疏，固定带宽效果不好。

动态目标提取出来之后，可以和视觉或者激光雷达的检测结果做关联，验证一致性。我试过把雷达动态簇投影到图像上，和视觉检测框对比，大部分情况下能对上，少数对不上的往往是视觉漏检或者雷达虚警，这种交叉验证对提升感知鲁棒性很有帮助。

4. 常见问题排查与实操避坑指南

4.1 点云读取与解析的典型故障

雷达数据处理的第一个坑往往出现在读取阶段。最常见的问题是 pcd 文件解析报错，提示字段数量不匹配或者格式异常。这通常是因为 devkit 版本和数据集版本不匹配。nuScenes 有过几次数据格式更新，老版本 devkit 读新数据会出问题。解决办法是确认 devkit 版本和数据集版本对应，官方文档里有版本对照表。

第二个常见问题是读出来的点云数值异常，比如坐标全是零，或者速度值大得离谱。坐标全零多半是文件路径错了，读到了空文件或者占位文件。速度值异常一般是字段顺序问题，前面提过，不同版本对速度字段的位置定义可能不同。你可以先打印原始数组的前几行，对照官方文档确认字段含义。

第三个问题是内存溢出。雷达点云虽然单帧不大，但如果你一次性加载整个序列的所有帧，内存会爆。建议用生成器或者分批加载，处理完一帧释放一帧。我一般会写一个迭代器，按 sample 逐个 yield 点云，这样内存占用稳定。

4.2 坐标系变换错误的定位方法

坐标系变换错误的表现是点云位置整体偏移或者旋转错乱。定位这类问题，我有一套固定流程。先检查外参，把 calibrated_sensor 的平移和旋转打印出来，看看数值是否合理。雷达安装位置一般在车体坐标系下几十厘米到一米多的范围，旋转角度不会太夸张。如果数值明显不对，说明标定 token 取错了。

再检查变换顺序。旋转和平移的顺序不能反，正确顺序是先旋转再平移。如果你先平移再旋转，结果会完全错。这个错误很隐蔽，因为代码看起来只是两行交换，但结果差很多。我建议你把变换写成矩阵形式，用四乘四齐次矩阵一次性完成，这样不容易出错。

最后检查坐标系定义。nuScenes 的车体坐标系和激光雷达坐标系定义不同，车体坐标系原点在车辆后轴中心附近，激光雷达坐标系原点在传感器本身。如果你把两者混用，点云会整体偏移。确认清楚每个坐标系的原点和轴向，是排查变换问题的基本功。

4.3 速度补偿的常见误区

速度补偿最容易犯的错是用错参考系。径向速度是在雷达坐标系下测的，所以投影视线方向必须用雷达坐标系下的点坐标。如果你用变换后的车体坐标去算视线方向，投影结果就错了。这个错误不会导致点云位置异常，只会让速度值偏，所以很难通过可视化发现，只能靠逻辑检查。

第二个误区是忽略时间戳。自车速度用相邻帧差分算，时间间隔必须用真实时间戳差。nuScenes 的雷达帧率不是严格固定的，用帧号差当时间差会引入误差。我一般会从 sample_data 里取 timestamp 字段，做微秒级差分，再换算成秒。

第三个误区是速度平滑过度。平滑能降噪，但过度平滑会把真实的加速度变化抹掉。我的经验是做三到五帧的滑动平均就够了，再多会滞后。如果你做的是紧急制动或者急加速场景，平滑窗口还要再小。

4.4 多雷达融合的疑难杂症

多雷达融合最常见的问题是重叠区点云密度不均。前面提过，重叠区点会重复，导致局部密度过高。解决办法是做体素栅格下采样，把空间划分成小格子，每个格子只保留一个代表点。格子大小根据你的任务定，做检测可以大一点，做分割要小一点。

第二个问题是不同雷达的标定误差导致同一目标分裂成多个簇。这个在远距离尤其明显，因为角度误差在远距离会放大成较大的位置偏差。缓解办法是在融合前对每个雷达点做距离相关的误差补偿，或者用概率方法做关联，而不是简单拼接。

第三个问题是时间不同步导致的运动模糊。高速场景下，五个雷达的时间差会让运动目标在不同雷达里位置不一致。解决办法是按时间戳对每个雷达点做位姿插值，补偿到统一时刻。这个操作计算量大，但对高速场景是必要的。

4.5 常见问题速查表

这张表是我在实际调试中慢慢攒出来的，基本覆盖了八成以上的常见问题。你遇到新问题的时候，可以先对照这张表定位方向，大部分情况能快速缩小范围。

5. 雷达数据进阶用法与扩展思路

5.1 基于雷达点云的时序跟踪

雷达点云虽然稀疏，但速度信息让它在时序跟踪上有独特优势。传统跟踪靠位置关联，雷达可以额外用径向速度做关联，提高数据关联的准确率。具体做法是：对相邻帧的雷达点，先做位置最近邻匹配，再用速度一致性做二次筛选，速度差超过阈值的匹配对剔除。这样能有效减少误关联，尤其在目标交叉或者遮挡场景下。

实现上，你可以用卡尔曼滤波做状态估计，状态量包括位置和速度，观测方程里同时用位置和径向速度。雷达的径向速度观测精度比位置观测高，所以速度项的权重可以给大一些。我试过在车辆跟踪上对比纯位置跟踪和位置加速度跟踪，后者在目标机动时收敛更快，轨迹更平滑。

5.2 雷达与视觉的早期融合尝试

早期融合是指在特征层面融合雷达和视觉，而不是在结果层面。雷达点云可以投影到图像平面，生成一个稀疏的速度图或者深度图，和图像特征拼接后送入网络。这种融合方式能让网络同时利用视觉的纹理信息和雷达的速度信息，对运动目标分割特别有效。

投影的时候要注意相机和雷达的标定关系。nuScenes 提供了相机和雷达各自的外参，你需要先统一到车体坐标系，再通过相机内参投影到像素平面。投影后，每个雷达点对应一个像素位置，把径向速度填进去，就得到稀疏速度图。速度图很稀疏，可以用插值或者卷积做稠密化，再和图像特征融合。

我试过用这种方式做运动目标分割，雷达速度图作为额外通道输入，分割精度比纯视觉有提升，尤其在视觉纹理弱或者光照差的场景下。不过雷达点太稀疏，稠密化会引入噪声，需要设计合适的融合模块来抑制。

5.3 恶劣天气下的雷达鲁棒性验证

雷达的一个核心优势是恶劣天气下性能稳定。nuScenes 里有雨天、夜间等场景，你可以对比雷达和视觉、激光雷达在这些场景下的表现。我做过一个简单验证：在雨天场景下，视觉检测的召回率明显下降，激光雷达点云也有衰减，但雷达点云的数量和速度分布基本稳定。这说明雷达在恶劣天气下是可靠的冗余模态。

验证方法上，你可以统计不同天气条件下各模态的检测数量、点云密度、有效探测距离等指标，做横向对比。雷达的指标波动最小，这为多模态融合提供了依据。如果你做的是安全冗余系统，雷达应该作为必选模态，而不是可选。

5.4 雷达数据在其他任务上的迁移

除了感知，雷达数据还能用在定位和建图上。雷达点云虽然稀疏，但静止物体的雷达回波在时序上稳定，可以做扫描匹配。nuScenes 提供了高精度地图和自车位姿，你可以用雷达点云和地图做配准，验证定位精度。我试过用雷达点云做简单的里程计，低速下精度还可以，高速下因为点稀疏，漂移比较明显，需要和惯性或者其他模态融合。

另一个方向是用雷达数据做场景理解，比如区分可通行区域和障碍物。雷达对金属物体反射强，对植被和地面反射弱，这个特性可以用来做粗糙的地面分割。不过雷达点太少，单独做分割效果有限，更适合作为辅助特征。

6. 实操环境搭建与完整流程复现

6.1 环境准备与依赖安装

先把环境搭起来。我用的组合是 Python 3.8 以上，nuscenes-devkit 官方包，加上 numpy、scipy、open3d 做点云处理，matplotlib 做可视化。安装 devkit 直接用 pip 就行，但要注意版本，建议装官方文档推荐的版本，避免和数据集不匹配。

pip install nuscenes-devkit pip install numpy scipy open3d matplotlib

如果你要用深度学习框架，pytorch 或者 tensorflow 按自己习惯装。我一般用 pytorch，因为点云相关的库支持好一些。装完之后先跑一下 devkit 自带的示例，确认能正常读取数据，再做后续操作。

6.2 完整读取与处理流程代码框架

下面给一个完整的处理框架，从读取到变换到速度补偿，你可以直接参考。代码里我加了详细注释，关键参数都标出来了。

import numpy as np from nuscenes.nuscenes import NuScenes from nuscenes.utils.data_classes import RadarPointCloud from pyquaternion import Quaternion # 初始化 nusc = NuScenes(version='v1.0-trainval', dataroot='你的数据路径', verbose=True) # 取一个 sample sample = nusc.sample[0] # 遍历雷达通道 radar_channels = ['RADAR_FRONT', 'RADAR_FRONT_LEFT', 'RADAR_FRONT_RIGHT', 'RADAR_BACK_LEFT', 'RADAR_BACK_RIGHT'] all_points = [] for channel in radar_channels: # 取 sample_data sd_token = sample['data'][channel] sd = nusc.get('sample_data', sd_token) # 读取点云 pc = RadarPointCloud.from_file(nusc.dataroot + '/' + sd['filename']) points = pc.points.T # 转成 N x 5 # 有效性过滤 valid = (points[:, 4] > -20) & (np.linalg.norm(points[:, :3], axis=1) < 200) points = points[valid] # 坐标变换到车体坐标系 cs = nusc.get('calibrated_sensor', sd['calibrated_sensor_token']) rotation = Quaternion(cs['rotation']).rotation_matrix translation = np.array(cs['translation']) points_ego = points[:, :3] @ rotation.T + translation all_points.append(np.hstack([points_ego, points[:, 3:5]])) # 合并 merged = np.vstack(all_points) print('合并后点数:', merged.shape[0])

这段代码跑通之后，你就拿到了车体坐标系下的五路雷达融合点云。速度补偿的部分需要相邻帧的 ego_pose，我单独写一个函数处理。

6.3 速度补偿函数实现

def compensate_velocity(nusc, sample, radar_channel, prev_sample): # 取当前帧和前一帧的 ego_pose sd = nusc.get('sample_data', sample['data'][radar_channel]) prev_sd = nusc.get('sample_data', prev_sample['data'][radar_channel]) ego = nusc.get('ego_pose', sd['ego_pose_token']) prev_ego = nusc.get('ego_pose', prev_sd['ego_pose_token']) # 时间差 dt = (sd['timestamp'] - prev_sd['timestamp']) / 1e6 # 微秒转秒 if dt <= 0: return None # 自车位移和速度 delta = np.array(ego['translation']) - np.array(prev_ego['translation']) ego_velocity = delta / dt # 读取点云 pc = RadarPointCloud.from_file(nusc.dataroot + '/' + sd['filename']) points = pc.points.T # 雷达坐标系下的视线方向 ranges = np.linalg.norm(points[:, :3], axis=1) ranges[ranges == 0] = 1e-6 los = points[:, :3] / ranges[:, None] # 自车速度投影到视线方向 ego_radial = los @ ego_velocity # 补偿 compensated = points[:, 3] - ego_radial return points, compensated

这个函数返回原始径向速度和补偿后的径向速度。你可以对比两者，看看自车运动的影响有多大。实测下来，城市低速场景影响较小，高速场景影响明显，补偿前后速度差能达到每秒好几米。

6.4 可视化验证与结果检查

处理完一定要可视化验证。我一般用 open3d 做三维显示，把雷达点云和激光雷达点云叠加，雷达按速度着色，激光雷达按高度着色。如果雷达点落在激光雷达物体上，且速度分布合理，说明流程正确。

import open3d as o3d # 雷达点云 radar_pcd = o3d.geometry.PointCloud() radar_pcd.points = o3d.utility.Vector3dVector(merged[:, :3]) # 按速度着色 vel = merged[:, 3] vel_norm = (vel - vel.min()) / (vel.max() - vel.min() + 1e-6) colors = plt.cm.jet(vel_norm)[:, :3] radar_pcd.colors = o3d.utility.Vector3dVector(colors) # 激光雷达点云 lidar_sd = nusc.get('sample_data', sample['data']['LIDAR_TOP']) lidar_pc = LidarPointCloud.from_file(nusc.dataroot + '/' + lidar_sd['filename']) # 变换到车体坐标系后叠加显示 o3d.visualization.draw_geometries([radar_pcd, lidar_pcd])

可视化的时候注意视角，俯视图看整体分布，侧视图看高度对齐，前视图看前向覆盖。多换几个视角，能发现很多数值上看不出来的问题。

7. 个人实操心得与后续扩展建议

折腾 nuScenes 雷达数据这段时间，最大的体会是雷达模态的门槛不在算法，而在数据处理的细节。坐标系、时间戳、速度补偿，每一个环节都有坑，而且这些坑不会报错，只会让结果悄悄偏掉。我的建议是每做一步都做可视化验证，不要等整个流程跑完再看结果，那样排查成本太高。

另一个体会是雷达数据的价值需要结合任务来挖掘。如果你做的是纯视觉检测，雷达可能帮助有限；但如果你做的是运动估计、恶劣天气感知、多模态冗余，雷达就是不可替代的。选对任务方向，比盲目堆数据处理技巧更重要。

后续扩展上，我打算试试用雷达速度做自监督学习，让网络从雷达速度中学习运动表征，再迁移到视觉任务。另外多雷达的联合标定优化也是个方向，nuScenes 的标定参数是固定的，但实际部署中标定会有漂移，如何在线估计和补偿值得研究。这些想法还在验证阶段，有进展再分享。