-
Notifications
You must be signed in to change notification settings - Fork 30
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
90 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
# 自动驾驶建图--道路边缘生成方案探讨 | ||
#### 一、背景 | ||
对于自动驾驶来说,建图是必不可少的,目前主流厂商技术都在从HD到"无图"进行过渡筹备中,不过想要最终实现真正的"无图"还是有很长的一段路要走。 | ||
对于建图来说,包含了很多的道路元素,车道线,停止线,斑马线,导流属性,道路边缘以及中心线(包含引导线)等。这里,中心线的预测通常是根据轨迹,通过数学公式进行拟合,目前学术上逐渐采用模型进行预测,但是对于下游(PNC)来说,还是存在不够平滑,曲率不够精准等问题,不过这个不在本次方案讨论范围内,先忽略,以后有空可以写一写。 | ||
道路边界对于PNC来说也是至关重要,约束车辆行驶范围,避免物理碰撞发生。通常道路边界的生成有几种方法,一种是当做车道线的一部分,跟着模型一起输出,但是没有车道线的特征明显,容易漏检,而且道路边界是异形的,基于分割的方案会比基于Anchor的方案效果稳定一些。另一种是HD的方法,根据处理后的车道线,按照距离和规则等虚拟出道路边界线。本文给出一种新的解决方案,略微繁琐,但是优点是可以延用已有的公开数据集进行处理生成,快速落地验证,缺点是本方案不具备时效性,是离线的方法。 | ||
|
||
#### 二、方案 | ||
|
||
**数据集&模型** | ||
整个方案的pipline如上图所示,为了快速验证效果,所以直接采用了公开的数据集BDD100k,这个数据集主要是用于可行驶区域, 车道线以及全景分割等。它的车道线有标边线,但是没有区分类别,没办法直接用,所以采用freespace来进行验证。模型方面,理论上采用任何一个分割都可以,这里采用的是YOLOPv2, 模型提供了训练好的权重和推理脚本,输出如下所示。 | ||
|
||
<figure style="text-align: center;"> | ||
<img src="https://pic1.zhimg.com/80/v2-7975b86889f5fcdf657704316c371451_1440w.jpeg" alt="图像"> | ||
<figcaption >YOLOPv2输出</figcaption> | ||
</figure> | ||
|
||
**差异性** | ||
这个数据集存在一个与建图的需求有所差异的问题,刚才提到这个方案是基于freespace做的,但是freespace是以实际能看到的边界作区分的而不是道路的边界,所以和实际建图的需求有一些diff,上面图里面能看到绿色的就是freespace的结果,被左边的车挡住了道路的边界,所以freespace就会以车辆边界作为自身的界限。如果是实时的没有什么问题,但是离线的话会产生diff,如果第一天有车,建图后,第二天发现没有车,那么可通行的范围就被压榨了。所以后续如果实际使用,需要以道路的边界作为freespace的边界线。 | ||
|
||
<figure style="text-align: center;"> | ||
<img src="https://pic1.zhimg.com/80/v2-59c2f64267e415b466a9e11d31b8eddc_1440w.png" alt="图像"> | ||
<figcaption >overview</figcaption> | ||
</figure> | ||
|
||
**整体方案** | ||
整个方案的pipline如上所示,对前视摄像头得到的图像进行畸变矫正后,喂进模型,输出对应的freespace,由于IPM对于边界以及远处的投影效果不好的问题,所以只选取车前15m,左右20m的范围,得到的freespace根据内外参以及自车位置投影到世界坐标系下。通过连续帧的叠加,可以生成世界坐标系下的2d点云。实际上需要的是边缘,所以还需要对点云进行处理得到道路的边缘,这里有尝试过PCL以及AlphaShape等点云处理方法,能解决部分case的提取,但是还是依赖于调参,没办法自动化处理,下面有一些bad case示例。 | ||
|
||
1. 世界坐标系2d点云 | ||
<figure style="text-align: center;"> | ||
<img src="https://picx.zhimg.com/80/v2-aded8ccba31e696ec96dc8b385f16949_1440w.png" alt="图像"> | ||
<figcaption >2d点云</figcaption> | ||
</figure> | ||
|
||
1. PCL | ||
<figure style="text-align: center;"> | ||
<img src="https://picx.zhimg.com/80/v2-e279903725d0ecfd9f5141ef00518578_1440w.png" alt="图像"> | ||
<figcaption >pcl滤波+边缘提取结果</figcaption> | ||
</figure> | ||
|
||
1. AlphaShape | ||
<figure style="text-align: center;"> | ||
<img src="https://picx.zhimg.com/80/v2-d259d67b533dce85f2075ae74dde665c_1440w.png" alt="图像"> | ||
<figcaption >alphashape提取结果</figcaption> | ||
</figure> | ||
|
||
针对上面的问题,首先对世界坐标系的点云进行投影映射,我这里设置的是1个像素表示0.05m,因为一个车道线大概15-20cm宽,所以这一点点的误差不影响反投影回去的结果。映射后,可以得到栅格的点云,由于从uv到世界坐标系转换中,远处的点会发散,所以在栅格图像中需要对其进行过滤和填充处理,处理前后如下图所示。 | ||
<figure style="text-align: center;"> | ||
<img src="https://pic1.zhimg.com/80/v2-b2c370763c99748f0396607c5b43a0f6_1440w.png" alt="图像"> | ||
<figcaption >栅格处理</figcaption> | ||
</figure> | ||
|
||
然后可以用图像处理的方法得到整个栅格图的边缘并根据映射关系反投影到世界坐标系下,根据下游的需求对矢量化的点进行稀疏采样或者插值处理,结果如下所示。 | ||
<figure style="text-align: center;"> | ||
<img src="https://pica.zhimg.com/80/v2-0242bb74e3eeda58425191d70b413247_1440w.png" alt="图像"> | ||
<figcaption >边缘处理</figcaption> | ||
</figure> | ||
|
||
接下来一步,就是需要根据RTK信息来对边缘的两端进行截断(不然封闭的区域车也没发行驶),此步骤略微繁琐,逻辑简化如下: | ||
- 根据属性判断是否是直行,转弯还是掉头路口等 | ||
- 根据不同的属性,设置不同的切分逻辑 | ||
- 直行|转弯,采用双头切分,分别根据起始和终止RTK位置,通过设置距离参数来找训左右两端的切分点进行切分。 | ||
- 掉头,采用单头切分,选定起始位置后定位关键点,通过设置较长的距离来贯穿整个掉头路口,定位4个点进行切分。 | ||
- 过滤异常点,平滑处理。 | ||
<figure style="text-align: center;"> | ||
<img src="https://picx.zhimg.com/80/v2-a26f836f5028d6577b20a7430d38e674_1440w.png" alt="图像"> | ||
<figcaption >切分前后效果,这里蓝色是切分后的边缘</figcaption> | ||
</figure> | ||
|
||
|
||
最后,就是不断的优化和迭代的逻辑了,模型效果不好那就优化模型,逻辑不够鲁邦就优化逻辑。之前有提到数据集中的freespace不是以实际道路边缘边界区分的,所以后面还需要标数据进行模型优化。 | ||
|
||
为了验证精度是否够高,可以拼接到HD上进行对比 | ||
<figure style="text-align: center;"> | ||
<img src="https://picx.zhimg.com/80/v2-2d5c85fd1d17bac75c86d53a762b7490_1440w.png" alt="图像"> | ||
<figcaption >底图是hd提供的车道线和参考线,红色是路口的道路边界</figcaption> | ||
</figure> | ||
|
||
最后的最后,PNC实际上用不了这种异形的边缘的,事实证明了,一切的一切还是要向HD看齐,所以还要根据生成的边缘来做二次约束进行曲线平滑优化处理。这里就不展开讲了,又是一个非常复杂的数学问题。 | ||
<figure style="text-align: center;"> | ||
<img src="https://pica.zhimg.com/80/v2-0957f6c4b19a336d140881ea715d6c6d_1440w.png" alt="图像"> | ||
<figcaption >基于边缘约束优化后效果</figcaption> | ||
</figure> | ||
|
||
|
||
#### 三、结论 | ||
本方案只是提供了一种快速落地的思路,里面实际上还有很多的细节问题需要进行优化。不过基于freespace的方案相比于只去预测道路边缘的方案来说,泛化能力相对来说会强一点,同时可以一份标注数据多种用途。不过速度上需要注意,离线可以满足要求,在线实时还是要看优化的效率。 | ||
|
||
有想要交流的可以在评论区留言或者私信我 | ||
|
||
**注: 本方案已经申请专利** |