当前位置: 首页 > news >正文

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 坐标系,才能一起使用。

为什么需要多颗雷达? 因为雷达本身的探测角、距离与分辨率受限,单个雷达无法可靠覆盖车辆周围所有方向(尤其是近距侧后角和盲区),所以工程上用多颗毫米波雷达分布在车身不同位置来实现环视感知、冗余与分工

  1. 有限的视场角(FOV)

    • 一颗雷达通常有一定的水平/垂直波束宽度,不能同时覆盖 360°。多个雷达可实现全车环视,覆盖前、侧、后不同角度。
  2. 距离/分辨率与分工

    • 制造上会有长距窄束(用于前方远距离探测,检测远速移动车辆)和短距宽束(用于侧后近距离、盲区监测、泊车)两类雷达。多雷达按任务分工效率更高。
  3. 消除遮挡与盲区

    • 车辆自身(车身、货物)或其它车辆会产生遮挡。多视角可以互补,减少漏检。
  4. 冗余与功能安全

    • 自动驾驶/ADAS 要求冗余传感以提高可靠性 —— 某颗故障/受污染时其它传感器仍可工作。
  5. 速度 + 位置联合估计更稳健

    • 多个雷达在不同角度观测同一目标,有助于更准确地估计目标的横向/径向运动、做多传感器跟踪与数据关联。
  6. 工程与成本考虑 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里)

每个点要经过两步变换:

  1. 传感器坐标系 → 车体坐标系(ego frame)

    • calibrated_sensor(外参,给出传感器相对于车体的旋转和平移)。
  2. 车体坐标系 → 全局坐标系(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点云对齐在同一空间,
    否则模型输入会乱套。
  • 这一步是所有 传感器融合数据集预处理可视化 的必备前置操作。
http://www.xdnf.cn/news/1323469.html

相关文章:

  • 特种行业许可证识别技术:通过图像处理、OCR和结构化提取,实现高效、准确的许可证核验与管理
  • Android Cutout(屏幕挖孔)详解
  • Python day48.
  • 【笔记ing】考试脑科学 脑科学中的高效记忆法
  • OCR库pytesseract安装保姆级教程
  • Zephyr下控制ESP32S3的GPIO口
  • 飞算JavaAI家庭记账系统:从收支记录到财务分析的全流程管理方案
  • 上下文切换及线程操作相关内容
  • 微信小程序通过uni.chooseLocation打开地图选择位置,相关设置及可能出现的问题
  • 开放最短路径优先协议
  • Python装饰器:从入门到精通
  • QNX 性能分析工具(hogs pidin tracelogger)
  • IOPaint 远程修图:cpolar 内网穿透服务实现跨设备图片编辑
  • Less (CSS 预处理器)
  • 贪心算法(Greedy Algorithm)详解
  • html页面打水印效果
  • 跨平台RTSP播放器深度对比:开源方案与商业SDK的取舍之道
  • 无人机迫降模式技术要点解析
  • 【C语言16天强化训练】从基础入门到进阶:Day 2
  • 基于ssm jsp中学校园网站源码和答辩PPT论文
  • 深入解析StatefulSet与K8s服务管理
  • 解锁 JavaScript 高级技能:从基础到实战的进阶指南
  • 【案例】ECharts 环形图中心下移后,如何保持中间图片和文案居中
  • 20250818在荣品的PRO-RK3566开发板跑Buildroot的时候使用在线秒表https://tool.hiofd.com/stopwatch/
  • 决策树:机器学习中的强大工具
  • 机器学习(决策树)
  • VLN视觉语言导航(3)——神经网络的构建和优化 2.3
  • 理解AQS的原理并学习源码
  • 大厂 | 华为半导体业务部2026届秋招启动
  • Spark 运行流程核心组件(三)任务执行