这套 Oxford Radar RobotCar Dataset 我前前后后折腾了挺长时间。如果你正在做自动驾驶、机器人定位或者毫米波雷达相关的方向，大概率绕不开这个数据集。它出自牛津大学机器人研究所，是在真实城市道路环境下用多传感器采集的，重点是加入了四台毫米波雷达，并且提供了和激光雷达、摄像头、GPS/INS 对齐好的数据。这篇笔记我不打算讲官网上已经写得很清楚的东西，而是把我从下载、解析、可视化到踩坑的整个过程记录下来，给后面要用的人省点时间。
1. 先弄清这套雷达数据能做什么，再决定要不要入坑
1.1 它本质上是一套“带雷达模态”的自动驾驶多模态数据集
Oxford Radar RobotCar Dataset 是牛津 RobotCar 数据集的一个雷达扩展。原来的 RobotCar 数据集用一辆改装过的日产 Leaf 在牛津市区反复采集了超过一年时间，覆盖了不同季节、不同光照、不同天气下的真实道路场景。雷达扩展版本重点加入了一套 Navtech CTS350-X 毫米波雷达系统，同时保留了激光雷达、双目相机、GPS/INS 等传感器。
这套数据的典型应用场景非常明确：
- 毫米波雷达里程计（radar-only odometry）和回环检测
- 毫米波雷达与激光雷达、相机、惯导的多传感器融合定位
- 基于雷达的静态地图构建与动态目标检测
- 恶劣天气、低光照条件下与视觉方案的性能对比研究
和 KITTI 这类数据集相比，它的优势在于雷达模态是完整的原始极坐标数据，不是已经处理好的点云。这既是优点也是门槛：优点是你可以完全按照自己的算法来做信号处理，不用被别人的预处理绑住手脚；缺点是你不能像读 pcd 文件那样直接吃现成的结果，自己得处理不少雷达信号的东西。
1.2 传感器配置：四部雷达到底是怎么装的
这四台雷达不是简简单单复制四份。它们分成了两组安装位置，每组包含一部向上倾斜和一部向下倾斜的雷达，分别装在车头和车尾。这样布局的目的是尽量兼顾近距离盲区和远距离环境感知：朝下的雷达主要负责车身附近和路面区域，朝上的雷达看更远的环境结构。
除了四台毫米波雷达，车上还有：
- 三台 SICK LMS-151 二维激光雷达，其中一台朝前，两台斜向布置，覆盖车体周围不同区域
- 两台 Point Grey Bumblebee XB3 双目相机，分辨率 1280x960，拍摄车前后方画面
- 一套 NovAtel SPAN-CPT 组合导航系统，提供 GPS 定位和光纤陀螺仪 IMU 数据，输出 50Hz 的位姿信息
- 一套额外的秒级脉冲同步装置，用于将各个传感器的时间戳统一到 GPS 时间上
这套配置放在今天来看依然是相当豪华的传感器阵列。尤其是雷达和激光雷达同时存在，意味着你可以做非常公平的“毫米波雷达 vs 激光雷达”对比实验，而不用自己费劲去标定安装位置。
2. 雷达坐标系和两种数据格式，搞不懂后面全是坑
2.1 原始极坐标数据是怎么组织的
Oxford Radar RobotCar Dataset 的雷达数据存储分成两种形态：navtech格式和cartesian格式。很多人第一次拿到的其实是 cartesian 格式，但真正想深入研究的主儿，最后都得回到 navtech 格式去看原始信号。
navtech 格式保存的是极坐标下的原始测量结果。Navtech CTS350-X 这类机械旋转雷达的工作原理是：雷达天线在水平面内做 360 度旋转，每到一个角度就向外发射调频连续波，然后接收回波。整个一圈扫描下来，得到的是一个以“方位角 x 距离”为组织的二维强度图。假如你把这个数据直接可视化成图像，会发现它的横轴是方位角，纵轴是径向距离，画面看起来就像一张被展开的环形图。
实际从官方 SDK 里加载出来的数组，维度会随发布版本不同有差异，一般是一组形如(帧数, 采样点数量, 通道数)的张量，其中采样点数量通常能达到数万个级别。每个采样点的通道包括距离信息、方位角信息以及回波强度。这里特别提醒一句：不要拿 KITTI 那种“已经转好笛卡尔坐标”的思维去硬套，navtech 格式的核心就是极坐标强度图，你后续所有算法都得从这里开始。
2.2 从极坐标转笛卡尔坐标，比想象中容易出错
雷达极坐标转到笛卡尔坐标，数学上不复杂：
x = r * cos(a) y = r * sin(a)也就是把每个距离-方位角采样点，用它的径向距离 r 和方位角 a，投影到以雷达为原点的平面坐标系里。但这里有几个实际工程问题：
第一，极坐标网格在角度方向是均匀采样的，转到笛卡尔坐标后，远处的点会变得稀疏。大家常说的“雷达点云远端点距越来越大”，就是这个原因。所以很多方法会在远距离部分降采样，或者直接在极坐标域做处理，避免硬转。
第二，多普勒效应。毫米波雷达回波本身带有径向速度信息，但开源出来的这份数据并不直接提供每个点的多普勒速度。如果你是做目标跟踪的，需要自己用帧间匹配去估算速度，不能指望数据给现成的。
第三，强度值的动态范围非常大。金属护栏、路牌的回波强得吓人，路面的回波又可能弱到看不见。直接做可视化的话，必须做对数变换或者设置强度阈值，不然画面就是一团黑底里几个白点。
2.3 雷达、相机、激光雷达之间的坐标标定关系
多传感器数据集能不能直接用，很大程度上取决于标定文件做得完善不完善。Oxford 这套数据的标定相当完整。SDK 里提供了雷达坐标系、激光雷达坐标系、相机坐标系以及车辆本体坐标系之间的变换矩阵。
你拿到手的转换关系一般长这样：
T_radar_to_vehicle = 4x4 的齐次变换矩阵 T_lidar_to_vehicle = 4x4 的齐次变换矩阵 T_camera_to_vehicle = 4x4 的齐次变换矩阵注意这里的约定很重要：官方用的是从传感器坐标系到车辆坐标系的变换。你要把雷达点转到相机图像上，得先radar -> vehicle，再vehicle -> camera，最后再做相机内参投影。方向一旦搞反，点云和图像怎么都对不上。
我自己的经验是，拿到 SDK 后先写一个“点云投影到图像”的最小脚本，把标定流程跑通，再进入正式的算法开发。如果这一步不先验证，后面做数据融合时会浪费大量时间在排查坐标问题上。
3. 从下载到可视化，亲手跑通一个雷达扫描
3.1 下载数据与搭建实验环境
数据下载在官网上提供了多个序列，每个序列对应一次完整行车采集。序列命名一般是日期加编号，比如2019-01-10-11-46-21这种格式。下载时注意，除了雷达数据，一定要把对应的gps、ins、stereo、lidar数据一起拉下来，否则后面做时间同步没有参考。
我个人的建议是下载时别一次全选所有文件，先找一个序列的雷达数据和一个序列的图像数据，跑通全部流程再批量下载。这些 npy 文件体积不小，一个序列的雷达数据经常几十 GB，硬盘不够的极容易卡在半路。
环境方面，官方 SDK 依赖的是 C++ 和 Python 的混编。Python 端主要依赖这个几个库：
numpy matplotlib opencv-python scikit-image值得多说一句的是 scikit-image 在极坐标转笛卡尔的可视化里非常方便，尤其是skimage.transform.warp_polar这类函数，能帮你快速把极坐标图像拉直或者反向投影。不过正式的算法处理我建议还是手写转换逻辑，因为 skimage 的一些默认参数会做插值和平滑，这会污染信号强度。
3.2 读取 navtech 格式雷达数据并可视化
先看一段最简单的读取代码。假设你下载好的 npy 文件路径是radar_navtech/下的某个文件：
import numpy as np import matplotlib.pyplot as plt data = np.load("path/to/radar_scan.npy", mmap_mode="r") print("data shape:", data.shape) # 取其中一帧。不同 release 的通道顺序不一样，先打印形状确认。 scan = data[0] print("single scan shape:", scan.shape) # 如果是 (N, 40000, 3) 这种，最后一维可能是 azimuth 角度、range 索引和强度。 # 这里只做强度可视化，先取亮度通道。 intensity = scan[..., 2].astype(np.float32) plt.imshow(intensity, aspect="auto", cmap="gray") plt.colorbar() plt.savefig("radar_intensity_polar.png", dpi=150)这段代码跑通后，你会得到一张极坐标强度图。横轴是方位角索引，纵轴是距离索引。画出来的图像可能和你想象的“雷达数据”完全不同——它更像一幅条纹图案，而不是直观的俯视图。
想得到直观的俯视图，需要把极坐标转成笛卡尔坐标。下面这段代码给出一个最直接的实现：
angles = np.linspace(0, 2 * np.pi, scan.shape[0], endpoint=False) ranges = np.arange(scan.shape[1]) # 建立角度和距离的网格 angle_grid, range_grid = np.meshgrid(angles, ranges, indexing="ij") # 极坐标转直角坐标 x = range_grid * np.cos(angle_grid) y = range_grid * np.sin(angle_grid) # 把强度值放到笛卡尔平面 intensity = scan[..., 2].astype(np.float32) fig, ax = plt.subplots(figsize=(8, 8)) sc = ax.scatter(x.ravel(), y.ravel(), c=intensity.ravel(), s=0.01, cmap="gray") plt.savefig("radar_cartesian.png", dpi=150)注意这里使用scatter画几万个点是没问题的，但如果你画完整帧甚至连续帧，会因为点太多导致绘图极慢。后面自己处理的时候，建议用numpy直接做网格重采样，或者先对强度图做阈值过滤，只保留有效回波点。
3.3 把雷达数据和相机图像对齐
这是很多人一开始最容易懵的地方。雷达坐标系和相机坐标系不同，雷达看的是 2D 水平切面，相机看的是 3D 空间在 2D 平面的投影。所以即便你有了标定矩阵，也不能直接把所有雷达点投影到图像上。
正确做法是：
- 把雷达点从雷达坐标系转到车辆坐标系
- 去掉那些高度明显超出雷达安装平面的点（因为雷达是 2D 的，所有点都在同一个平面上，但这些点在车辆坐标系下有对应的高度）
- 把车辆坐标系下的点转到相机坐标系
- 用相机内参把三维点投影到图像像素坐标
流程用代码表示大致是这样：
import numpy as np # 已知的外参和内参 T_radar_to_vehicle = np.load("path/to/T_radar_to_vehicle.npy") T_camera_to_vehicle = np.load("path/to/T_camera_to_vehicle.npy") K = np.load("path/to/camera_intrinsic.npy") # 假设 points_radar 是 Nx3 的雷达坐标系下的点 points_radar = np.zeros((N, 3)) # 雷达系 -> 车辆系 points_vehicle = (T_radar_to_vehicle[:3, :3] @ points_radar.T).T + T_radar_to_vehicle[:3, 3] # 车辆系 -> 相机系（需要求逆） T_vehicle_to_camera = np.linalg.inv(T_camera_to_vehicle) points_camera = (T_vehicle_to_camera[:3, :3] @ points_vehicle.T).T + T_vehicle_to_camera[:3, 3] # 相机系 -> 像素坐标 depth = points_camera[:, 2] u = (K[0, 0] * points_camera[:, 0] / depth) + K[0, 2] v = (K[1, 1] * points_camera[:, 1] / depth) + K[1, 2] # 只保留在图像范围内的点 mask = (u >= 0) & (u < 1280) & (v >= 0) & (v < 960) & (depth > 0)这里最关键的坑是：车辆坐标系和相机坐标系的零点不在同一个位置，而且雷达的安装高度、俯仰角度都会直接影响投影结果。如果你的外参标定文件里包含雷达相对地面的高度，一定要确认变换矩阵里已经包含了这一项，否则投影出来的点会整体偏差。
4. 雷达数据处理中的常见坑，整理成速查表
4.1 时间戳同步：雷达慢、相机快，怎么对齐
传感器时间戳必须统一到同一个时钟上。Oxford 这套数据的时间同步机制做得不算复杂：所有传感器都接收 GPS 时间源的秒脉冲信号，所以时间戳的基准是统一的。但问题在于不同传感器的帧率完全不同。
雷达大约 4Hz，激光雷达大约 13Hz，相机大约 11Hz，GPS/INS 是 50Hz。你做融合时不可能要求它们在同一时刻都有数据，所以惯常的做法是选择某个“主传感器”的时间作为基准，然后用其他传感器的测量进行插值或者寻找最近邻帧。
我的经验是：做雷达里程计时，以雷达时间为基准，把 INS 位姿数据插值到雷达时间戳上；做视觉与雷达对齐时，以相机时间为基准，寻找时间上最接近的雷达帧，再对雷达帧做运动补偿。
4.2 极坐标转笛卡尔时最容易出的两类问题
极坐标转笛卡尔，看起来十几行代码就能搞定，但实践中会碰到两个非常隐蔽的问题。
第一个是尺寸和分辨率失配。极坐标图像在角度方向是等间隔的，但距离方向的分辨率也有限。转到笛卡尔坐标后，近处网格可能密密麻麻，远处网格则稀疏得漏点。如果你不做插值，直接画散点图，会得到一张“中间密、四周稀”的图，这其实不是传感器坏了，而是投影本身带来的采样不均。处理办法是先设定一个目标分辨率，比如每像素 0.2 米，然后用二维直方图累加或者插值方式把强度值填充进去。
第二个是坐标系方向约定。有的代码默认角度从 x 轴正方向逆时针转，有的默认从 y 轴正方向顺时针转，还有的雷达驱动会额外加入安装角的偏置。Oxford 官方数据里雷达的 0 度角方向并不是车辆正前方，而是有一个固定偏置。你不处理这个偏置，点云整体会旋转一个角度。拿 SDK 里的标定矩阵反推一下就知道了，但很多人会忽略这一步。
4.3 动态物体、多径和运动畸变
雷达数据里常见三个物理层面的问题。
多径效应是雷达里非常典型的现象。雷达波在金属表面之间来回反射，会产生一个虚假的回波点，位置看着合理，实际对应的是并不存在的物体。城市环境中，道路护栏、建筑物玻璃幕墙、大型金属车体都是多径反射的高发区。处理多径目前没有通用的一劳永逸方案，常见的思路是利用回波强度、几何一致性做滤波，或者在多帧之间做动态一致性检验。
运动畸变则是因为机械旋转雷达成像需要时间。CTS350-X 扫描一圈大约需要 250 毫秒左右，车辆在行驶过程中已经移动了一段距离。假设车以 36km/h 行驶，250 毫秒就是 2.5 米。也就是说，雷达一圈扫描的末尾部分，相对起点已经发生了 2.5 米的位移。如果不做运动补偿，拼接出来的点云在视角上会有“扭曲”。消除运动畸变的标准做法是用 IMU 或 GPS 位姿对每个方位角下的采样点补偿车体运动，把每个点都换算到同一个坐标系。
我在这上面栽过跟头。最开始我用一整帧雷达做点云配准时，发现明明静态环境，配准结果却总有一块系统性误差。后来才意识到是运动畸变没有补偿。建议拿到数据后先做一次圆周扫描时间内的位姿插值，把点云帧里的每个点都按方位角对应的时间戳修正位置。
5. 能用它做什么方向，以及我自己的实操心得
5.1 雷达里程计：在没有 GPS 的环境里靠雷达自己走
雷达里程计是 Oxford 这套数据集上最热的方向之一。因为毫米波雷达不受光照和一般雨雾天气影响，比相机和激光雷达都更稳。学术上有不少方法把极坐标强度图输入到深度学习网络里做特征提取，或者用传统 ICP 方式在笛卡尔点云上做配准。
如果你要做这个方向，我的建议是不要一上来就上深度学习。先在极坐标图上做一个稳定的特征提取和匹配，你会更直观地理解雷达数据的特性。等把几何基础弄明白了，再用网络去学习那些手工特征很难覆盖的场景，会发现模型效果提升非常明显。
5.2 目标检测、分割与多传感器融合
雷达的稀疏点云和强反射特性，决定了它在目标检测方向上有非常不一样的挑战。行人的雷达反射截面小，容易被当作噪声；金属护栏的反射强，可能被误检为障碍物。纯雷达做三维目标检测在精度上很难打过激光雷达，这是物理限制决定的。但雷达有一个激光雷达没有的优势：它的多普勒信息能直接反映目标的径向速度，只不过 Oxford 这套数据的开源版本没有直接给多普勒信息，需要你自己做帧间匹配去估计。
多传感器融合是这个数据集的杀手锏场景。雷达负责提供全天候感知，激光雷达提供高精度几何结构，相机提供语义信息，惯导提供高频位姿约束。你可以按自己的融合策略自由置换输入模态，这在很多数据集中是做不到的。我之前做过一个实验：在下雨场景下，视觉里程计直接崩掉，纯雷达里程计虽然漂移增大但还能维持基本轨迹，融合上惯导之后表现就很稳了。这种实验结论写论文特别有说服力。
5.3 实操心得与小技巧
最后分享几个我自己日常处理这个数据集时留下来的固定习惯：
- 先建立“极坐标图”和“笛卡尔点云”两套数据管线，不要只保留其中一套。极坐标图适合做信号处理和特征提取，笛卡尔点云适合做几何配准和可视化。两套管线并存只多写几十行代码，但以后每换一个算法都能省下大量时间。
- 遇到坐标对齐问题，先从最简单的场景开始验证。找一个空旷环境下的数据，打开雷达点云和相机图像，手动找一个明显目标（比如路灯杆），然后调整变换参数，直到点和图像中的目标重叠。不要上来就调试网络模型，先保证数据流程是对的。
- 使用
np.memmap加载大文件。数据集的单个 npy 文件往往非常大，直接np.load容易把内存吃满。用mmap_mode="r"可以只把需要用到的帧调入内存，处理完就释放，对长时间调试非常友好。 - 实验记录比实验结果更重要。雷达数据处理中各种参数的微小差异都可能带来巨大影响：距离分辨率、角度偏移、强度阈值、运动补偿的插值方式。我每次跑实验都会把参数记到一个固定的配置文件中，确保结果可复现，否则过两周再回头看，连自己都不记得当时是怎么调出来的。
我自己回头看，这套数据集确实值得花时间钻进去。它不像一般点云数据集直接把结果喂到你嘴边，但恰恰是这种“需要自己处理信号”的特性，能逼着你把雷达原理、坐标变换、时间同步这些基础概念真正搞明白。等你在 Oxford 的数据上把雷达里程计调通，再回头看其他雷达数据，思路会清晰很多。
