数据集—OpenScene

Occupancy Network

3D框 检测与固定输出尺寸联系起来-目标中心
体素-网格中心 体素(Voxel)- 三维像素 二维的叫像素
   体积像素,‌即空间中的小块体积元素
    2018 年在论文「Occupancy Networks: Learning 3D Reconstruction in Function Space」
	   把世界划分为一系列网格单元,然后定义哪个单元被占用,哪个单元是空闲的
	   预测 3D 空间中的占据概率来获得一种简单的 3D 空间表示
点云分割--各个点

OCC和BEV

鸟瞰图 (BEV) 空间、
    从2D空间到3D空间
	  bev是二维的呈现形式把所有的结果在高度上拍扁了,而occupancy则是三维的
固定矩形:
    3D框 
	体素:将世界划分为微小(或超微小)的立方体或体素预测每个体素是空闲还是被占用
      任意形状和无限类别的真实世界物体	
	  occupancy相比原来的bounding box,细粒度更高,更加能够表达物体的细节了
物体检测
    这个空间是空闲的还是被占用的,不管对象的类别是什么
	每个占据单元同时也包含分类信息
	用占位网络隐含地表示表示任意拓扑结构的高分辨率几何图形	
	一般为概率值,表示voxel存在物体的概率
	
预测::Occupancy volume
    光流估计和 Occupancy flow	
	    体素的流动,因此每辆车的运动都可以知道
		 每个对象的方向:红色:向前 — 蓝色:向后 — 灰色:静止等……(实际上有一个色轮代表每个可能的方向)	 
	语义信息和速度信息(Occupancy Flow)	 	 
		 以目标为中心的感知
         以网格为中心的感知--移动机器人			 

语义场景补全(Semantic Scene Completion, SSC)

 语义场景补全在semantic kitti上有个task,他的真值是对激光雷达数据的逐点标注,把他体素化后就可以拿来做occupancy的预测
 3D Semantic Scene Completion更关注于从稀疏的输入数据中恢复出完整的3D场景的几何和语义信息,
 而Occupancy则更侧重于通过体素网格来表示和理解3D空间的占用情况。
 	Occ任务一般只关注于物体是否占用了该体素空间,而SSC需要预测占用该体素空间的物体的所属类别。	 	 
 	oxel占据状态一般可以分为3种:Occupied(被占用的)、Free(空闲的)、Unobserved(无法被观测的)	 

3D语义分割

3D语义分割是基于点级别的,是需要评估模型对每个点(点云)、像素(图像)的分类的准确性,
而Occ是基于体素的,是需要评估模型是否能准确的判断每个体素是否被占用。
  其中3D语义分割的真值是每个点的标签,每个点的标签表示了这个点所属的类别;
  Occ的真实是体素标签,每个体素的标签表示了这个体素是否被占用。
  3D点云语义分割的图像,每个点都包含了这个点属于什么类别的信息
  3D语义分割更注重于这个物体的类别,而Occ更注重这个空间的体素是否被占用了,输出的该体素被占用的概率

真值生成或标注

Occupancy真值通常不会直接进行人工标注,因为直接人工标注的难度较大,往往需要借助3D box的位置和语义信息间接生成。
真值数据标注
    通过稀疏点云数据生成
	     已有三维目标检测和三维分割标签-多帧时序激光雷达点云
	三维重建领域   
    稠密三维占据标注	

OpenScene 数据集

   是用于自动驾驶领域端到端规划、视觉预训练和占用预测的大型数据集
   https://github.com/OpenDriveLab/OpenScene
Mini数据集
    openscene_metadata_mini.tgz		509.6 MB
    openscene_sensor_mini_camera	84 GB
    openscene_sensor_mini_lidar	    60 GB

数据集解释

类别
   1 车辆 Vehicle, 
   2 自行车 Bicycle, 
   3 行人 Pedestrian, 
   4 障碍物 Barrier, 
   5 交通锥 Traffic cone, 
   6 施工标志区 Construction zone sign, 
   7 通用对象 Generic object, 
   8 背景 Background
评测指标
    IOU  mIOU 
    总的数据: Duration 1521 logs, 120+ hours
	采集地点: 拉斯维加斯(64%)、新加坡(15%)、匹兹堡(12%)、波士顿(9%)
	场景类别: 22种行为 22种策略 8种区域 18种交互 5种动力变化
    每个场景时长scenes: 20s 大约20秒  帧率2Hz Frequency of tracks/ego: 2hz
    mini (64 logs)

数据结构

   L: LiDAR, C: Camera	  mini (64 logs)
   Voxel	Range: [-50m, -50m, -4m, 50m, 50m, 4m]; Size: 0.5m
    log_name  log_token
    scene_name  scene_token
    
    token   frame_idx  timestamp
    vehicle_name ego_dynamic_state  driving_command
    lidar_path  lidar2ego_translation  lidar2ego_rotation  ego2global_translation  ego2global_rotation
               'lidar2global'  'lidar2ego'    'ego2global'  
    cams  CAM_F0  data_path  sensor2lidar_rotation  sensor2lidar_translation  cam_intrinsic  distortion
       ['CAM_F0','CAM_B0','CAM_L0', 'CAM_R0','CAM_L1','CAM_R1','CAM_L2','CAM_R2']
    'sample_prev'  'sample_next'     
   anns  instance_tokens  track_tokens  gt_boxes  gt_names  track_tokens
    occ_gt_final_path 
	flow_gt_final_path'	
    dataset/openscene-v1.0/occupancy/mini/log-003-scene-0056/occ_gt/025_occ_final.py	

OpenScene_openscene-v1.1

 ├── meta_datas
        |     ├── mini
        │     │     ├── 2021.05.12.22.00.38_veh-35_01008_01518.pkl
        │     │     ├── 2021.05.12.22.28.35_veh-35_00620_01164.pkl
        │     │     ├── ...
        │     │     └── 2021.10.11.08.31.07_veh-50_01750_01948.pkl 
        └── sensor_blobs
              ├── mini
              │    ├── 2021.05.12.22.00.38_veh-35_01008_01518                                           
              │    │    ├── CAM_F0
              │    │    │     ├── c082c104b7ac5a71.jpg
              │    │    │     ├── af380db4b4ca5d63.jpg
              │    │    │     ├── ...
              │    │    │     └── 2270fccfb44858b3.jpg
              │    │    ├── CAM_B0
              │    │    ├── CAM_L0
              │    │    ├── CAM_L1
              │    │    ├── CAM_L2
              │    │    ├── CAM_R0
              │    │    ├── CAM_R1
              │    │    ├── CAM_R2
              │    │    └── MergedPointCloud
              │    │            ├── 0079e06969ed5625.pcd
              │    │            ├── 01817973fa0957d5.pcd
              │    │            ├── ...
              │    │            └── fffb7c8e89cd54a5.pcd       
              │    ├── 2021.06.09.17.23.18_veh-38_00773_01140 
              │    ├── ...                                                                            
              │    └── 2021.10.11.08.31.07_veh-50_01750_01948

Each .pkl file is stored in the following format:

CooC

VOC数据格式是一种用于图像标注的标准格式,它用于存储图像及其相关的标注信息。
     在VOC格式中,每张图片的标注标签信息会被保存到一个XML文件中
COCO(Common Objects in Context)数据集是COCO2017
  数据集中categories id 是不连续的
 coco数据集的标注文件是.json文件,
    全部的数据标注文件由三个.json文件组成:train.json val.json test.json
yolo数据集的标注文件是.txt文件,(每个.txt文件和.jpg文件是一一对应的)
    在label文件夹中每一个.txt文件对应数据集中的一张图片
     左上角坐标(x,y)、目标框的宽度和高度 (w,h) 构成,统称为bounding box (BBox)。

KiTTi

KITTI
SemanticKITTI:SemanticKITTI 是KITTI家族的一个显著扩展 
  3D box, segmentation, depth, flow

nuScenes

  3D box, segmentation
###数据集 
 nuPlan是世界上第一个大规模的planning benchmark  发布于2021年
   传感器: 5x激光雷达(20Hz)   8x 相机(10Hz) 1个IMU
   数据标注:
     Maps: 提供了2d HDmap的人工标注,例如路、人行道、十字路口、车道、交通灯等
     可行驶区域上的Vehicle、Bicycle、Pedestrian、Traffic cone、Barrier、Construction zone sign、generic object,
        还有一部分人行道上和自车驾驶相关的目标。
    nuplan_v1.1_mini版 
  工具链	

数据标注

标注数据
    标注2D/3D边界框
	标注分割数据
	   图像分割:
	       Polygon:即采用轮廓点的方式存储,是n*2的数组,存储的是每个点的坐标
	       Mask:是与原始图像具有相同尺寸的二值掩码图,1为目标区域,0为背景区域	
	标注轨迹--轨迹本质是一些列的点
	   驾驶过程中涉及归队驾驶环境中各种实体的路径或运动模式进行标注
	   例如车辆-行人和骑行者--标注过程依赖于目标检测和跟踪的结果

    标注的形式:
      点-线-框-立方体等
    	多边形分割掩码 
		游程编码(Run-Length Encoding, RLE)是一种常用的数据表示方法,特别是在处理二值掩码(binary mask) 

参考

https://openxlab.org.cn/datasets/OpenDriveLab/OpenScene/tree/main 
posted @ 2025-01-03 17:46  辰令  阅读(253)  评论(0)    收藏  举报