nuScence数据集
Metadata [US, Asia] — 0.43 GB
- 这个文件包(通常是一个 zip/tgz)包含 nuScenes 的元数据和标注:JSON 格式的关系型表(scene、sample、sample_data、ego_pose、calibrated_sensor、instance、category、attribute、visibility 等)、地图/拓扑信息索引、版本说明、split 列表和 evaluation config 等。它不包含原始图像/点云二进制数据,只是描述和注释(labels + 时间戳 + 校准)。下载并放到数据根目录后,devkit 能据此索引原始文件
File blobs of 85 scenes, part 1 [US, Asia] — 29.41 GB
- nuScenes 把原始传感器文件(相机图片、LiDAR sweeps、Radar sweeps 等二进制资产)按场景分片(blobs),每个“part”包含 85 个 scene 的全部 sensor 文件。Trainval 总共 850 scenes,因此被分为 10 个 part(每个 85 scenes)以便分批下载。
File blobs of 85 scenes, part 1
就是第一块 sensor 数据集合(包含该 85 个场景下的所有 sensor 文件,视你选的子项而定)
Keyframe blobs only for part 1 [US, Asia] — 4.22 GB
- Keyframe = 被注释的 frame(sample),nuScenes 在 keyframes 上提供标注(annotation),keyframe 的采样频率是约 2 Hz(每 0.5s 一个 keyframe)。这个包“只包含 keyframe 的 sensor 文件” —— 即每个 keyframe 时间点下对应的相机图像 / lidar sweep / radar(取决于打包策略),不包含那些非 keyframe 的额外中间帧或所有 sweeps,因此体积明显小。适合只想用带标注帧做训练/快速验证的场景
Lidar blobs only for part 1 [US, Asia] — 12.80 GB
- 仅包含该 85 个场景中与 LiDAR 相关的原始文件(即 LiDAR sweeps / 点云二进制文件)。注意 nuScenes 的 LiDAR 频率大约 20Hz,所以如果下载 全部 sweeps 体积会比较大(比只下 keyframes 大得多)。如果你的任务是基于 LiDAR 的训练/重建/可视化,就必须拿到这些文件
Radar blobs only for part 1 [US, Asia] — 0.22 GB
- 仅包含 Radar 原始数据。Radar 文件相对较小(每帧数据轻),所以体积通常很小。若你不做 Radar 相关工作,可以不下载
Camera blobs only for part 1 [US, Asia] — 16.39 GB
- 仅包含该 85 个场景中所有相机的图片文件(6 个相机、按 12Hz 的采样率),因此通常是单模态里最大的一个包(大量图像)。如果你只需要 keyframes(2Hz 的带标注帧),可只选 Keyframe blobs(体积更小);若要使用所有 camera sweep(例如做连续帧的任务),就要下载 camera blobs
为什么会按这些分包?
-
方便按需下载:full trainval 有上百 GB(上 TB 级别取决于扩展),一次性下载不现实。nuScenes 把数据按 85-scene 分片并允许按模态(camera/lidar/radar)或只要 keyframes 的方式,方便只拿需要的子集(节省带宽和磁盘)。
-
选择策略:
- 要做3D detection(LiDAR-first):通常至少下载
Metadata + Lidar blobs
(并可能需要 Camera blobs 作融合)。 - 要做图像(camera)相关任务:下载
Metadata + Camera blobs
或只下Keyframe blobs
(如果只需要带标注帧)。 - 要跑快速 demo / 开发:先下
v1.0-mini
或只下Metadata + Keyframe blobs for part X
。
- 要做3D detection(LiDAR-first):通常至少下载
-
[US, Asia] 链接是下载镜像/区域选择,按你所在地区或官方服务器位置选择更快的镜像。
- 快速开发 / debug:下载
v1.0-mini
(小样本,官方教程常用)或只下Metadata + Keyframe blobs
的第一块 - 完整训练(包含时序/sweeps):下载
Metadata + File blobs of 85 scenes
(所有 part)或按模态下载 camera/lidar 全量包(并合并所有 part) - 节省空间:只下你需要的模态(例如只做 LiDAR-only,就不用下载 camera blobs)。
- 把文件解压后目录结构:确保
v1.0-trainval/
、samples/
、sweeps/
、maps/
(如有)在同一个数据根目录下,nuscenes-devkit 的NuScenes(version, dataroot)
就能正常读取
什么叫 “frame”(帧)
- 在 nuScenes(或者一般多传感器数据集/系统里),frame 指的是车辆在某个时间点的统一感知快照。
- 每一帧都对应一个 ego vehicle pose(车体坐标系位置 + 朝向),是所有传感器在该时间点的参考坐标系。
- 所有传感器(相机、LiDAR、雷达)在这一帧的数据,都会通过坐标变换对齐到这个 ego 坐标系,才能一起使用。
为什么需要多颗雷达? 因为雷达本身的探测角、距离与分辨率受限,单个雷达无法可靠覆盖车辆周围所有方向(尤其是近距侧后角和盲区),所以工程上用多颗毫米波雷达分布在车身不同位置来实现环视感知、冗余与分工
-
有限的视场角(FOV)
- 一颗雷达通常有一定的水平/垂直波束宽度,不能同时覆盖 360°。多个雷达可实现全车环视,覆盖前、侧、后不同角度。
-
距离/分辨率与分工
- 制造上会有长距窄束(用于前方远距离探测,检测远速移动车辆)和短距宽束(用于侧后近距离、盲区监测、泊车)两类雷达。多雷达按任务分工效率更高。
-
消除遮挡与盲区
- 车辆自身(车身、货物)或其它车辆会产生遮挡。多视角可以互补,减少漏检。
-
冗余与功能安全
- 自动驾驶/ADAS 要求冗余传感以提高可靠性 —— 某颗故障/受污染时其它传感器仍可工作。
-
速度 + 位置联合估计更稳健
- 多个雷达在不同角度观测同一目标,有助于更准确地估计目标的横向/径向运动、做多传感器跟踪与数据关联。
-
工程与成本考虑 vs LiDAR
- 顶部 LiDAR 提供很好的 360° 高分辨率点云,但成本高、安装受限;雷达便宜且适合在车身多个位置部署(角落、保险杠内等),实现近距离侧后覆盖更经济。
各个雷达的典型角色(对应 nuScenes 的命名)
RADAR_FRONT
:前向长/中距离探测(高速路况下预警与目标速度估计)。RADAR_FRONT_LEFT
/RADAR_FRONT_RIGHT
:前侧斜角覆盖,检测交叉口、侧向来车、并减少前方盲区。RADAR_BACK_LEFT
/RADAR_BACK_RIGHT
:后侧/并线盲区、倒车与横穿交通检测(交叉路口、停车场)。
在 nuScenes 数据中为什么以多个文件夹出现
因为数据就是按 每个物理传感器(sensor) 导出的:每颗雷达的采样文件单独存在对应文件夹(samples/ 或 sweeps/ 下的 RADAR_FRONT
等)。这样你能按传感器读取、校准并把各雷达点云变换到相同坐标系做融合。devkit 的 metadata(calibrated_sensor / ego_pose)会告诉你如何把某颗传感器的数据变换到车体/全局坐标系。
-
坐标变换:读取某颗雷达的点云后,要用其
calibrated_sensor
(旋转和平移)和对应ego_pose
做时序/坐标对齐,才能把不同雷达的点合并到同一 frame。 -
ego-motion补偿:雷达给出的速度通常需要做车体速度(IMU/odometry)补偿以获得目标真实速度。
-
时间戳对齐:不同传感器采样频率不同,融合时需以 sample token 或时间戳对齐(nuScenes 的 samples/map 帮你索引)。
-
噪声/虚警:雷达点稀且噪声大,通常先做质量滤波、速度门控、脉冲杂波抑制再用于检测/跟踪。
-
高程(z)精度有限:别指望雷达像 LiDAR 那样给出细节 z 值;用于高度判断时要慎重或与 LiDAR/相机融合。
-
多雷达是 覆盖、分工、冗余与成本权衡 的产物:单颗雷达难以同时兼顾前远距、侧近距和后方盲区。
-
nuScenes 按物理传感器导出数据,所以你会看到多个
RADAR_*
文件夹,每个文件夹是对应安装位置的雷达数据。 -
在处理时要做坐标 / 时间 / ego-motion 对齐并做噪声过滤与速度补偿。
为什么要把多个雷达点合并到同一 frame
每个雷达的数据原始坐标系是它自己安装位置的局部坐标系(sensor frame)。
举个例子:
RADAR_FRONT
在车头正前方,它的原始点云坐标是“以车头雷达为原点”的局部坐标。RADAR_BACK_LEFT
在车尾左侧,它的原始点云坐标是“以车尾左雷达为原点”的局部坐标。
如果你直接画这两份点云,会看到它们“各自为政”,没法拼在一起。
但实际上,它们观测的世界是同一个,只不过坐标系不同。
合并到同一 frame 就是把不同雷达的数据通过标定信息(calibration extrinsics)和车体姿态(ego pose)转换到一个统一的 车体坐标系(ego frame) 或 全局坐标系(global frame),这样才能拼在一起使用。
转换流程(nuScenes里)
每个点要经过两步变换:
-
传感器坐标系 → 车体坐标系(ego frame)
- 用
calibrated_sensor
(外参,给出传感器相对于车体的旋转和平移)。
- 用
-
车体坐标系 → 全局坐标系(global frame)(可选)
- 用
ego_pose
(给出车辆在世界坐标下的位置与朝向)。
- 用
最终,你可以得到:
- 所有雷达点都在 同一个 ego frame(便于做 3D检测 / 多传感器融合 / 可视化)。
- 或者都在 global frame(便于和地图对齐)。
举个直观例子
假设车子在 (x=0,y=0),朝向正前方:
RADAR_FRONT
检测到一个点,坐标 (10, 0)(前方10米)。RADAR_BACK_LEFT
检测到同一个点,但在它的坐标系里可能是 (−2, 9)。
如果你不做变换,这两个点会画在完全不同地方,看似是两个物体。
经过外参转换到 ego frame 后,这两个点都会落在 (10, 0) 附近,你就知道它们实际上是同一个物体。
- 只有合并到同一 frame 后,你才能把多雷达的点云、相机图像、LiDAR点云对齐在同一空间,
否则模型输入会乱套。 - 这一步是所有 传感器融合、数据集预处理、可视化 的必备前置操作。