【论文阅读】点云地图动态障碍物去除基准 A Dynamic Points Removal Benchmark in Point Cloud Maps

【论文阅读】点云地图动态障碍物去除基准 A Dynamic Points Removal Benchmark in Point Cloud Maps

终于一次轮到了讲自己的paper了 hahaha，写个中文的解读放在博客方便大家讨论

• Title Picture

• Reference and prenotes

  paper: https://arxiv.org/abs/2307.07260

  code: https://github.com/KTH-RPL/DynamicMap_Benchmark

  b站：地图动态障碍物去除总结 ITSC’23: A Dynamic Points Removal Benchmark in Point Cloud Maps

1. Motivation

主要就是2019年末在公司的时候，做一个教育平台的无人驾驶小车项目的时候 从头开始部署autoware发现，建图中会有我们来来回回走动的 点云，当时其实就想了一种和 ndt slam 直接结合的方式去除，不过比较稚嫩+工程的想法所以后续也没有什么总结，隐约记得：最后还是 人手动去除的障碍物 毕竟也就三幅图

直到 2023年初 来了KTH后 天明又提了这个需求 问我能不能自动去掉Leica动态图，他人手标了KTH的图标了1个月，所以当时就又投入到这个idea的调研了，最后就是这一篇 + 后续两篇服务器托管网方案 的输出，那么开始进入正题

如图是截取KITTI 07的部分地图，因为有semanticKITTI的标注信息 所以我们把动态物体用黄色表示出来了，这个动态物体如果不在建图中去掉 可能会导致：

1. 定位出现问题，因为有大量不属于静态的点云出现在地图里导致错误的feature
2. 全局规划 无法规划，如上图 如果直接作为全局规划的global map，那么这一条路可能都不会被选择，有时候还可以绕路解决 但是如果黄色点再多 则直接gg 【不过这一点在自动驾驶中可能不会那么大的影响 因为大部分都会做地图矢量 OpenDrive的形式】
3. 建筑测量时，导致大量不准确的判断，主要就是用全站仪进行收集时，莱卡虽然内置去除 但是当数量较多时，也无法做到输出干净的地图

Contribution

那么对比之前方案 和 这篇的贡献主要在于：

1. 现有的方案 没有一个通用的基准测试以便后续研究者能够直接使用 一种格式进行测试 评估，所以我们在此总结了之前的方案，采用统一格式进行整理 删除多余的部分，给出一条更focus在这个任务上的benchmark
2. 之前的方案大多都是在仿真或KITTI上进行，而且都是64线雷达等，此篇我们同时还标注了 av2 32线大城市数据，semindoor 16线 半室内数据 并开放给大家一起评估使用。【后续随着两篇的出版还会 再开出 128线，莱卡全站仪数据】
3. 这篇提出基准的同时 也告诉了大家如何分析各个方案的问题并将其改进，比如我们选用了之前方案经常对比的octomap进行演示进行改进

2. Benchmark

基准测试包含四个方案 Removert，ERASOR，原octomap，改进后octomap，那么先整理一下方案 说明一下各自缺点 然后进入到实验给大家对应起各个问题

首先图2,3指示了三个方案各自的问题 【部分问题erasor文章中也进行了探讨 如果感兴趣 可以点进paper查看reference进行阅读】：

1. raycasting：采用雷达点 都是从中心射出去的性质，判断这条线的穿过部分都是空的点，但是会有：雷达角度 和稀疏雷达 导致的误判断动态点，删除了过多的点
2. visiting-based：采用可视区域（但是我在总结的时候 一直感觉和raycasting的基本差不多 没啥区别），也就是 一个激光点的光路穿过了另一个激光点，那么另一个激光点就是动态点 引用> Fig 2. (c) 可以看到如果超过一定高度的动态障碍物会导致 车顶部的点云无法有效被去除
3. height-threshold：也就是ERASOR的方案，用地图和当前scan的高度差异来判断，然后去除这个高度下的所有点，Fig 3. 指示了缺点：需要针对传感器高度，场景内出现的高度物体来进行调参，但是也避免不了无法找到一个合适的阈值解决一个场景内所有的高度，如果调高了会误删除很多点，如果调低了会 留下一些动态点

以下为方法总结：

我们的改进主要是针对benchmark和实验发现的问题进行的，在原始的octomap前加入了噪音去除，地面分割，然后octomap会根据每次scan的 给整个空间的每个voxel occupancy value 也就是这个voxel被占据的概率，最后运行完所有，我们根据概率阈值进行筛选动静态

同时需要注意的是 得益于octomap (c) 方案是唯一的不需要先验原始地图的，也就是后续如果能对时间进行改进 可以做到实时建图，最后直接输出clean map

3. Experiment

我们引入了新的两个数据集：

• AV2 的一个序列，配置为两个VLP32，上下连起来的中心放置方式 周边建筑物较高
• semindoor 我们自己在建筑楼下收集的数据，配置为一个VLP16，放在一个在地上的小车上

还有就是评估metric从 voxel-level 换成了 point-level，这样就不会对gt进行任何形式的处理 比如降采样等，也能保证最精准的评估，对标后续建筑领域的测量评估（全站仪）

定性分析 （看图）

首先趁热打铁，刚刚大家读完了 各个方案缺点，正好从实验可视化的角度看一看：

1. raycasting的问题 在图7的(d) 中得到了非常明显的体现，也就是 地面角度和雷达稀疏性 导致去掉了过多静态点，给地面造成了空洞 空洞的形状也正如雷达的ring
2. 关于车顶部点云无法去除 在KITTI05的数据中体现较多 因为文章篇幅 原文并没有能展示

不过随手拖一个Removert的结果图 可大家展示一下 当然大家自己也可以直接pull code或者docker pull来复现出来

3. height-based 在图6的(c) 可以看到树木的trunk 很规律的被高度截断，还有图中的其他部分 限于篇幅没有截图所有的，还有图7(c) 也可以看到一小块墙壁的高度面删除

---

那么从可视化角度，（note：ERASOR 我调过参，因为对高度阈值需要准确 16线的小车上不同于KITTI av2的也和kitti的高度不一样 所以为了对他们公平，就用了不同的config，其他的基本保持一个参数 比如我们改进后的octomap w GF阈值都是默认的一个

ERASOR和octomap w GF表现是比较好的，考虑下游任务，如果更追求精准度 octomap w GF更好，如果更追求去除的干净程度给部分不依赖 plane feature的localization用 可能ERASOR更好，预告：后续的两篇方法在时间和精度上均能够超过octomap w GF，欢迎大家star repo 以追踪信息

定量分析（看表）

• SA：静态点的准确率
• DA：动态点的准确率
• AA：联合准确率，(sqrt{SA times DA})，因为我可以去掉所有的点 让我的DA 100%，也就是一个点都不去让SA 100%，所以需要一个联合准确率去做最终的判断

从表的信息可以看出经过 benchmark指导 改进后的octomap w GF在大多时候表现还是较为优越的，虽然这并不是我们的最后结果（benchmark 比较站在中立的角度）

Fig 5指示了 没有标出来的动态点都在动态点哪个位置分布上，可以看到 基本都在动态点的周围，也就是说 后续可能经过一个cluster 距离的简单聚类 会再次提升DA的值（这也就是我们benchmark的意义：如何分析 – 分析后如何改进）

表二则是指示了 w GF后我们的速度提升 20-30%，当然还是不如Removert和ERASOR快，但是 在审的两服务器托管网篇方法为主 均在速度上有极大的提升

4. Conclusion

结论就是，这篇benchmark 大概就是给大家进行现有方案的总结，并且实验分析，改进其中一个老方案，给大家看到benchmark paper的意义，也可以说是survey paper（其实主要还是每个方法都有自己的格式 对比的都不开源 所以干脆自己干 搞一个 造福大家 一键生成与复现

最后就是 这个动态去除pipeline + simple ndt slam，可以做到给大家一条龙服务，需要做的就是rosbag record /point_cloud，录下你的雷达数据即可！

1. rosbag record
2. run simple_ndt_slam
3. run DynamicMap_Benchmark 其中任一方法均可

所有的代码和README均已完善，欢迎大家一起交流，如果有数据集 自己标了gt想要贡献的话 就更好啦！Stay tuned with us (因为后面还有更多方案会加进来哦

---

赠人点赞 手有余香 ；正向回馈 才能更好开放记录 hhh

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net

相关推荐: Flutter调优–深入探究MediaQuery引起界面Rebuild的原因及解决办法 | 京东云技术团队

前言 我们可以通过MediaQuery.of(context)方法获取到一些设备和系统的相关信息，比如状态栏的高度、当前是否是黑暗模式等等，使用起来相当方便，但是也要注意可能引起的页面rebuild问题。本文会介绍一个典型的例子，并深入源码来探讨引起rebui…