目录

数据集框架

JSON数据调用流程

总结

---

nuScenes数据集中各种数据定义，如scene，sample，sweep，sample_data，attribute等，对于初学者来说十分头疼，本人在最近也是学习了好久，想与大家分享一些自己的心得。

首先贴出nuScenes的官方文档（写的很详细，但对于初学者来说很难理解）：

https://www.nuscenes.org/nuscenes#overview

数据集框架

这里以nuScenes v1.0-mini版本为例，解压后可以看到三个文件夹：

其中，samples和sweeps文件夹内部结构相同，为各种传感器的详细数据（.jpg和.pcd文件）：

那问题来了，这两者的区别是什么呢？（这个问题困扰了本人好久）。
最终本人的理解是，samples里面储存的是在关键帧时传感器的数据，采样频率为2Hz。这些sample数据都具备相应的标注数据。而sweeps下面存储的是关键帧之间的数据，更加密集，但是缺少相应的标注，正常情况下训练时，只使用samples下的数据，即只使用有标注的关键帧数据做训练。

而v1.0-mini文件夹下面的架构如图：

可以看到有多个json文件，本人刚看到这里的时候属实是摸不到头脑。因此，梳理了一下整个json数据的调用过程，一步步地解析这些json之间的联系。

JSON数据调用流程

1. 日志数据 log.json ：

首先，起到总领全局作用的是log.json文件，记录了采集车辆名称、数据采集日期和采集地点等信息。可以看到下图中共有8个日志数据，前两个分别为在新加坡和波士顿采集的数据。

作用：可以根据token导入相关的地图数据（需要另外解压nuScenes的map数据集）。

2. 场景数据 scene.json :

场景scene的定义是一个20s左右的驾驶过程，nuScenes mini数据集中共有10个场景，如下：

可以看出，每个description都描述了场景的具体情况。而每个场景被分成每0.5s一个sample，所以nbr_samples的数量一般是在40左右。
那么如何确定这些nbr_samples的顺序呢？这里记录了first_sample_token和last_sample_token，而中间的sample_token具有prev和next，这些sample就像链表一样连接起所有的sample。

3. 样本数据 sample.json :

结构如下图所示，可以看到共有404个sample，即10个场景，每个场景20s，共40个sample（大约）。

可以看到第一个sample是链表的头节点，只有next，没有prev。之后，这些token会对应到sample_data和sample_annotation，即与传感器数据和标注数据关联。

4. 传感器数据 sample_data.json :

这里以图像数据为例，展示两个sample_data，如下：

可以看到共有31206个传感器数据。只算关键帧的话，共404个sample，激光雷达，毫米波雷达，摄像头加起来共12个传感器，因此有404*12=4848，远小于31206。说明sample_data中不只包含关键帧的传感器数据，还包含了大量非关键帧的数据。两张图片的filename中，一个来自samples，一个来自sweeps也说明了这一点。

再看数据的结构，不难推测一个sample_token会对应多个sample_data（共12个传感器，所以这里会是12个）。同时，每个sample_data还会有相应的ego_pose_token和calibrated_sensor_token，用于获取车辆在世界坐标系中的位置和姿态信息以及传感器校准信息。

5. 自车数据 ego_pose.json :

下图可以看出，ego_pose也有31206个，与sample_data是一一对应关系，记录了某一时刻采集传感器数据时，自车的世界坐标系中的位置和姿态信息。

6. 传感器校准信息 calibrated_sensor.json :

传感器校准信息如下所示，只有120个，这取决于采集数据集时用了多少个传感器，因此一个传感器校准信息会对应多个sample_data，为一对多的关系。

7. 标注信息 sample_annotation.json :

sample_annotation这里可能会有点绕，可以把sample_annotation理解为一个个标注框。共有18538个sample_annotation，也就意味着多个sample_annotation对应一个sample，为多对一。

这里首先明确一个概念，即instance(实例)的概念要比sample_annotation大，具体后面会讲。
每个sample_annotation具有一个visibility_token，代表其可见性。同时，还具有一个属性attribute，表明该标注的具体内容（例如车辆是运动还是静止）。这两个后续会讲到。

translation表示标注框在空间中的位置，size表示标注框的大小，rotation表示标注框的姿态信息。这里nuScenes的标注为3D标注。做图像检测时可以利用传感器（如相机）的内参矩阵和外参矩阵，将 3D 空间中的点投影到图像平面上。

8. 实例数据 instance.json ：

这里是最重要的一点，理解instance和sample_annotation的关系，他们之间的纽带就是sample。先举例进行说明：1个sample会对应多个sample_annotation，即每一帧场景会对应出现多个标注框（例如20个），而这20个标注框，可能会有4个实例，即对应四个instance。例如，有人.行人.成人，人.行人.儿童，车辆.摩托车，车辆.紧急救护车等四个。

instance结构如下：

共有911个instance。这么多的原因是，instance不可以跨scene(场景)传播，即每一个instance，只能限制在20s的驾驶场景中发挥作用。

category_token指的就是instance的类别，即上述例子中的车辆.摩托车，车辆.紧急救护车等等。

而nbr_annotations和first_annotation_token开始时让我感到疑惑。nbr_annotations指的是在某一个scene中，该instance被标注出来的数量，first_annotation_token和last_annotation_token则是指明了顺序。本人推测这样设计是方便看一个20s的驾驶场景中，某一个instance(实例)的整个运动过程，便于训练目标跟踪之类的。而sample_annotation一般用于目标检测。

9. 可见度visibility.json和属性attribute.json--sample_annotation下属模块

这两个模块很好理解。

visibility结构如下：

可以看到只有4类，代表从0-100%的可见度，即标注框在图像中的完整性。

attribute结构如下：

可以看到有8类，具体如下图所示。只有在sample_annotation对应的instance为车辆或者行人类型的时候，才会有attribute，表明其运动状态。

10. 实例类别 category.json :

共有23类，表明实例instance的各种类型：

总结

总的来说，nuScenes数据集的结构还是相当复杂的，不过在理解了整体的结构后，会发现这样的设计可以很好地对各个任务进行解耦，便于后续的使用！
大家多多点赞关注！