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。
[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点云对齐在同一空间，
否则模型输入会乱套。
这一步是所有 传感器融合 、数据集预处理 、可视化 的必备前置操作。