可通行区域检测理论全解析:从语义分割到多传感器融合的工程实践
发布时间:2026/10/20 9:03:08 锦皓数字建站

1. 可通行区域检测到底在解决什么问题先把场景说清楚。不管是移动机器人、低速无人配送车还是园区里的巡检设备只要它需要自己“走起来”第一件事就是回答一个问题我面前这块地到底能不能压过去这个问题听起来像废话但真正落到工程里它比“识别红绿灯”还要棘手。因为红绿灯是离散的、有明确语义的目标而可通行区域是一个连续的、边界模糊的、随视角和光照剧烈变化的区域概念。我见过不少刚入行的朋友一上来就想用目标检测那套思路——把“可通行”当成一个类别去框。结果就是框出来一堆重叠的矩形边界像狗啃的一样根本没法给下游的路径规划用。原因很简单可通行区域检测本质上是一个逐像素的语义分割问题而不是一个框回归问题。规划模块需要的是“这条线左边能走、右边不能走”这种精确到厘米级的边界而不是一个大概的矩形范围。所以这篇理论部分我想把这件事从头捋一遍。它适合谁看适合已经写过一些视觉代码、但对“为什么这么设计”还不太清楚的朋友也适合做规划控制、想理解上游感知到底在输出什么的工程师。我会把可通行区域检测的核心定义、数学表达、主流技术路线的底层逻辑以及那些文档里不会写的坑一条条摊开讲。你看完之后再去看任何一篇具体的分割网络论文或者工程代码心里都会有一张清晰的地图。先给一个最朴素的定义可通行区域是指在当前时刻、当前传感器视角下地面上一块满足“物理可通过”且“语义上允许通过”的连续区域。注意这里有两个约束。物理可通过说的是几何上不能有台阶、深坑、大石头语义上允许通过说的是哪怕地面平整但如果是草坪、是别人家的私人车道、是画了禁行线的区域那也不能走。这两个约束缺一不可而绝大多数纯视觉方案其实只解决了前一半。2. 从像素到区域可通行性的数学表达2.1 为什么用分割掩码而不是检测框我们先把“区域”这件事用数学语言说清楚。假设相机拍到的图像是 (I \in \mathbb{R}^{H \times W \times 3})那么可通行区域检测的目标就是学一个映射 (f)把图像映射成一个二值掩码 (M \in {0,1}^{H \times W})。其中 (M(i,j)1) 表示像素 ((i,j)) 属于可通行区域(0) 表示不可通行。这个映射和检测框的区别在哪检测框的输出是一个五元组 ((x,y,w,h,c))它描述的是一个矩形范围。而掩码是逐像素的它保留了完整的边界形状。你可以这样理解检测框像是用一把大刷子在地上画了个大概的圈而掩码是用一支细笔沿着路沿描了一遍。对于规划来说细笔描出来的边界才能用来算可行驶走廊的宽度大刷子画的圈只能用来做粗筛。但掩码也有它的问题。它是在图像平面上的而规划需要的是鸟瞰图BEV平面上的可通行区域。这就引出了一个关键的坐标变换问题也是理论部分必须讲透的地方。2.2 图像平面到鸟瞰平面的投影逻辑相机成像的过程是把三维世界投影到二维图像。而我们要做的是把二维图像反投影回三维地面。这个反投影能成立的前提是我们假设可通行区域都落在地平面上。这个假设在平坦道路上是成立的但在上下坡、减速带、坑洼路面上就会失效。这是纯视觉方案的一个根本性局限后面讲边界条件时我会再展开。反投影的核心工具是单应性矩阵Homography。设地面上一点在相机坐标系下的坐标为 (P_c (X_c, Y_c, Z_c))在图像上的像素坐标为 (p (u,v,1))。根据针孔相机模型[ p K \cdot [R | t] \cdot P_c ]其中 (K) 是相机内参矩阵([R|t]) 是外参。如果我们把世界坐标系定义在地平面上即 (Z_w 0)那么地面点和图像点之间就存在一个单应性关系[ p \sim H \cdot P_w ]这里的 (H) 是一个 (3 \times 3) 的矩阵它把地面上的二维坐标 ((X_w, Y_w)) 映射到图像像素 ((u,v))。反过来只要我们知道 (H^{-1})就能把图像上的每个像素反投影到地面坐标。实际工程里(H) 通常是通过标定得到的。标定的方法很简单在地面上摆几个已知位置的标志物记录它们在图像里的像素坐标然后用四组以上的点对解线性方程组就能求出 (H)。我个人的经验是标定用的点要尽量分散不要都挤在图像中央否则求出来的 (H) 在图像边缘会严重失真。另外标定完成后一定要做一次验证在地面上量一段已知距离反投影回去看误差有多大。如果误差超过 5 厘米那这个标定就不能用。2.3 可通行性的概率化描述现实世界里没有非黑即白的可通行性。一块区域可能“大概率能走但有点不确定”。所以更合理的做法是把可通行性建模成一个概率值 (P(M(i,j)1 | I))而不是硬性的 0 或 1。这个概率化描述有三个好处。第一它允许下游模块根据置信度做决策比如置信度低于 0.6 的区域就当作不可通行处理宁可保守一点。第二它方便做多传感器融合激光雷达给出的可通行概率和视觉给出的概率可以用贝叶斯公式融合。第三它让损失函数的设计更自然可以用二元交叉熵而不是硬分类的 hinge loss。我在实际项目里发现把可通行性输出成概率热力图比输出成二值掩码要好用得多。因为规划模块在做局部避障时可以根据概率值动态调整安全距离。概率高的区域贴着走概率低的区域提前绕开整个行为会显得更“像人”。3. 主流技术路线的底层逻辑拆解3.1 基于几何的方法地面平面拟合的局限最早期的可通行区域检测走的是纯几何路线。核心思想是地面是一个平面我用 RANSAC 或者最小二乘法把地面平面拟合出来然后看哪些点落在这个平面附近哪些点凸出来或者凹下去。这个方法在结构化道路上跑得还不错因为它假设地面是连续平坦的。但它有三个致命问题。第一它无法区分“地面上的平面障碍物”和“地面本身”。比如地上一块大铁板它也是平的几何方法会把它当成可通行区域。第二它对坡道无能为力因为坡道不是水平面拟合出来的平面会把坡道上的点判成障碍。第三它完全忽略了语义信息草坪和水泥地在几何上是一样的。所以几何方法现在很少单独使用更多是作为语义分割的一个补充特征。比如把地面平面的距离作为一个通道输入到分割网络里帮助网络更好地区分“地面”和“地面上的物体”。3.2 基于语义分割的方法从 FCN 到实时网络语义分割这条路是从全卷积网络FCN开始的。FCN 的核心贡献是证明了卷积网络可以端到端地输出逐像素预测而不需要全连接层。它的结构很简单用卷积层不断下采样提取特征再用反卷积层上采样恢复分辨率最后在每个像素上做分类。但 FCN 有个问题下采样会丢失空间细节导致边界模糊。于是有了编码器-解码器结构比如 SegNet 和 U-Net。编码器负责提取语义特征解码器负责恢复空间分辨率。U-Net 的跳跃连接skip connection把编码器的高分辨率特征直接拼接到解码器这对保留边界非常关键。再往后为了兼顾精度和速度出现了 DeepLab 系列。DeepLab 的核心是空洞卷积Atrous Convolution和空洞空间金字塔池化ASPP。空洞卷积的好处是不增加参数量的情况下扩大感受野ASPP 则是用不同膨胀率的空洞卷积并行提取多尺度特征。对于可通行区域检测来说多尺度特征特别重要因为近处的路面纹理和远处的路面纹理在图像上尺度差异很大。我实测下来的感受是如果算力允许DeepLabV3 的精度是最稳的如果要在嵌入式设备上跑MobileNetV3 加一个轻量解码器是更现实的选择。但不管用哪个网络输入分辨率都不要低于 512×512否则远处的可通行区域会糊成一片边界完全没法用。3.3 基于时序的方法为什么单帧不够单帧图像能提供的信息是有限的。一个坑从正面看可能只是一个颜色略深的区域但从侧面看就能看出深度。所以很多工程方案会引入时序信息用多帧来提升可通行区域检测的鲁棒性。时序方法有两种主流做法。一种是帧间特征融合把连续几帧的特征图在通道维度上拼接或者用 LSTM/GRU 做时序建模。另一种是光流辅助用光流估计出每个像素的运动然后根据运动一致性来判断哪些区域是地面。因为地面上的光流通常呈现规律的放射状分布而障碍物上的光流是杂乱无章的。光流辅助这个方法我试过效果确实有提升尤其是在纹理稀疏的路面上。但它的代价是计算量翻倍而且光流估计本身在快速运动时容易出错。所以我的建议是如果平台算力充足且运动速度不快可以上光流否则优先把单帧分割做扎实。3.4 多传感器融合的取舍纯视觉方案的天花板是明显的。逆光、雨雾、夜间这些场景下视觉的可靠性会急剧下降。所以工程上通常会融合激光雷达或者毫米波雷达。激光雷达的优势是直接提供三维几何信息不受光照影响。它的点云可以投影到图像平面给每个像素提供一个深度值。有了深度可通行区域检测就从一个纯语义问题变成了语义加几何的联合问题。比如一个像素被分割网络判为“地面”但激光雷达测出来它的深度比周围地面高出 20 厘米那它大概率是个凸起物应该判为不可通行。融合的方式有两种前融合和后融合。前融合是把激光雷达的点云特征和图像特征在输入层或者中间层就拼在一起让网络自己学融合权重。后融合是各自独立跑最后用贝叶斯或者投票的方式合并结果。前融合精度更高但需要精确的时间同步和空间标定后融合实现简单但容易在两者冲突时做出错误决策。我的经验是如果标定精度能做到 2 个像素以内就上前融合否则老老实实做后融合并且给激光雷达更高的权重。因为视觉在恶劣天气下会失效而激光雷达至少还能提供几何信息。4. 数据、标注与评估里的那些坑4.1 可通行区域标注为什么比想象中难标注可通行区域听起来就是“沿着路边画一圈”但实际做起来非常折磨人。第一个问题是边界定义模糊。路沿石算不算可通行如果车轮能压上去那算如果压上去会爆胎那不算。但标注员不知道你的车轮参数他只能凭常识判断。这就导致不同标注员画出来的边界能差出十几厘米。第二个问题是遮挡区域怎么标。一辆车停在路边车底下的地面被挡住了。这块区域是可通行的吗从物理上讲如果车开走了它就是可通行的但在当前时刻它被占用了。所以标注规范里必须明确遮挡区域一律标为不可通行还是标为“未知”。我倾向于标为“未知”然后在损失函数里忽略这些像素不让它们参与梯度计算。第三个问题是远处区域的标注精度。图像上远处的路面可能只占几十个像素但对应到实际地面上可能是十几米的范围。标注员在远处画错一个像素实际误差就是几十厘米。所以评估的时候远处的误差权重要降低不能和近处一视同仁。4.2 评估指标的选择与陷阱最常用的指标是 IoU交并比和 mIoU平均交并比。但这两个指标在可通行区域检测里有个陷阱如果可通行区域占了图像的 80%那么把所有像素都预测为可通行IoU 也能有 0.8。这个数字看起来很高但实际上模型什么都没学到。所以必须同时看边界区域的 IoU或者用Boundary F1-score。Boundary F1 只关注预测边界和真实边界附近的像素能更真实地反映边界质量。我通常会把这两个指标一起看整体 IoU 看召回Boundary F1 看边界精度。还有一个容易被忽略的指标是最大可通行宽度误差。这个指标是直接面向规划的在每一行像素上计算可通行区域的宽度然后和真实宽度比较。如果宽度误差超过 10 厘米规划模块算出来的可行驶走廊就会偏窄或偏宽直接影响行车安全。4.3 数据增强里的门道可通行区域检测的数据增强不能照搬图像分类那套。随机裁剪、旋转、翻转这些操作会破坏地面的几何结构。比如你把图像旋转 30 度地面的消失点就变了单应性矩阵就不对了。所以我的做法是只做颜色抖动、亮度调整、加噪声这些不影响几何的增强。如果要模拟不同视角应该用真实的相机外参变化去渲染而不是简单旋转图像。另外雨天和夜间的数据一定要单独采集不能靠后期加滤镜模拟。因为雨天的路面反光和夜间的灯光眩光是滤镜模拟不出来的。5. 边界条件与失效场景的深度分析5.1 坡道与起伏路面的几何失效前面提到过单应性矩阵假设地面是平面。但现实中的路有上坡、下坡、减速带。当车辆上坡时远处的地面在图像上的位置会比平面假设预测的位置更高。如果你还用平面单应性去反投影就会把坡道上的可通行区域错误地投影到更远的地方导致规划模块以为前面是平地实际上是个坡。解决这个问题有两种思路。一种是用 IMU 或者悬架传感器实时估计俯仰角然后动态调整单应性矩阵。另一种是用深度网络直接预测深度图然后用深度图做反投影而不是用平面假设。第一种方法成本低但只能处理整体俯仰处理不了局部起伏。第二种方法更通用但深度估计的精度在远处会下降。我实际用下来在园区低速场景下IMU 加动态单应性已经够用了。因为低速场景的坡道通常比较缓俯仰角变化不大。但在山区或者地下车库的陡坡就必须上深度估计了。5.2 光照突变与阴影干扰阴影是可通行区域检测里最阴险的敌人。一片树荫投在路面上颜色和周围路面差异很大分割网络很容易把它判成障碍物。但阴影本身是可通行的你压过去没有任何问题。解决阴影问题有几个方向。一是在训练数据里大量加入阴影样本让网络学会忽略阴影。二是用光照不变的特征比如把图像转换到 HSV 空间只用色相和饱和度不用亮度。三是用多帧信息因为阴影会随着车辆运动而变化而真实障碍物的位置是稳定的。我试过第二种方法效果有限因为阴影不仅改变亮度也改变色相。第一种方法最实在但需要采集大量带阴影的数据。第三种方法最优雅但实现复杂度高。所以我的建议是优先用数据驱动的方式解决把阴影当成一种需要覆盖的场景而不是试图用算法去“消除”它。5.3 透明与反光表面的误判玻璃幕墙、水面、抛光地面这些表面在图像上会反射周围环境导致分割网络完全懵掉。一块玻璃幕墙可能反射出天空和树木网络会把它判成天空或者植被而不是障碍物。这个问题在纯视觉框架下几乎无解因为视觉信息本身就有歧义。唯一的办法是引入其他传感器。激光雷达在玻璃上会直接穿透测不到回波这本身就是一个信号如果一个区域视觉上像障碍物但激光雷达测不到深度那它很可能是透明表面。反过来如果视觉上像可通行区域但激光雷达测到了异常深度那它可能是反光造成的假象。所以我的结论是在包含大量玻璃幕墙的园区场景里纯视觉方案不要单独上线必须配激光雷达做交叉验证。6. 从理论到工程落地的关键决策6.1 分辨率与感受野的平衡分割网络的第一层卷积感受野很小只能看到局部纹理。随着层数加深感受野逐渐扩大能看到更大范围的结构。对于可通行区域检测来说感受野必须覆盖到消失点附近否则网络无法理解“这条路通向哪里”。但感受野不是越大越好。太大的感受野会把无关区域的信息也混进来导致边界模糊。我的经验是感受野的直径应该是图像宽度的 1.5 到 2 倍。比如输入是 512×512感受野直径在 768 到 1024 像素之间比较合适。这个可以通过调整空洞卷积的膨胀率来控制。另外输入分辨率不要盲目追求高。1024×1024 的输入比 512×512 的输入计算量是 4 倍但精度提升可能只有 2 到 3 个百分点。在嵌入式平台上这个代价是不划算的。我通常会在 512×512 和 768×768 之间做权衡看平台的实时性要求。6.2 后处理里的形态学操作网络输出的掩码通常会有一些噪点和小空洞。这时候需要后处理来清理。最常用的是形态学开运算和闭运算。开运算先腐蚀后膨胀能去掉小的孤立噪点闭运算先膨胀后腐蚀能填补小的空洞。但形态学操作的核大小很讲究。核太大会把真实的窄通道也堵上核太小清理不干净。我的做法是核大小根据图像分辨率来定通常是图像宽度的 1% 到 2%。比如 512 宽的图像核大小用 5 到 10 个像素。另外形态学操作之后一定要再做一次连通域分析把面积过小的连通域直接删掉因为它们大概率是误检。6.3 与规划模块的接口设计可通行区域检测的输出最终要交给规划模块。这个接口设计得好不好直接决定了整个系统的行为表现。我见过两种接口。一种是直接输出二值掩码规划模块自己去做反投影和走廊提取。另一种是输出可行驶走廊的多边形感知模块把反投影和走廊提取都做完规划模块直接拿多边形去用。第一种接口灵活但把复杂度推给了规划。第二种接口简单但感知模块要承担更多责任。我倾向于第二种因为感知模块更了解自己输出的置信度能更好地处理不确定性。比如在置信度低的区域感知模块可以主动把走廊收窄给规划模块留出安全余量。接口的数据结构也很重要。我通常会用这样的结构一个多边形列表每个多边形包含顶点坐标和置信度分数。规划模块可以根据置信度决定是否使用这个多边形或者用多个多边形的交集作为最终的可行驶区域。7. 我在实际项目里踩过的几个坑第一个坑是标定漂移。相机装在一辆振动很大的车上跑了一段时间之后外参就变了。单应性矩阵还是旧的导致反投影出来的可通行区域整体偏移。后来我加了一个在线标定模块用地面上的车道线或者路沿作为参考实时修正外参。这个模块不复杂但能省掉很多返工的麻烦。第二个坑是训练集和测试集的场景泄漏。有一次我把同一条路的不同时间段数据分到了训练集和测试集结果测试精度虚高。因为网络记住了这条路的结构而不是学会了可通行区域的通用特征。后来我强制要求训练集和测试集必须来自不同的路段精度虽然降了但更真实。第三个坑是忽略了相机曝光时间的影响。白天曝光时间短运动模糊不明显晚上曝光时间长稍微颠簸一下图像就糊了。糊了的图像分割出来边界全是锯齿。后来我在晚上把曝光时间调短同时提高 ISO虽然噪点多了但边界清晰度反而更好。第四个坑是过度依赖单一场景的调参。在一个园区调好的阈值换到另一个园区就完全不能用。因为不同园区的路面材质、光照条件、路沿高度都不一样。所以我现在做项目一定会留出 20% 的数据做跨场景验证确保模型不是只对某一个场景过拟合。8. 理论部分的收束与延伸方向把可通行区域检测的理论部分捋到这里核心其实就三件事定义清楚什么是可通行选择合适的数学表达理解每种技术路线的边界。定义不清楚后面全是白费数学表达选错了精度上不去不理解边界上线就会出事故。如果你已经读到这里我建议你下一步做两件事。第一找一段你自己拍的路面视频手动标几帧可通行区域然后跑一个现成的分割网络看看它的输出和你的标注差多少。这个差距会让你对“理论精度”和“实际可用精度”有全新的认识。第二把你手头的相机做一次完整的标定包括内参和外参然后验证反投影误差。这个误差是你后续所有工作的基准基准不准后面全是空中楼阁。至于更远的方向我觉得有两个值得关注。一个是自监督学习用车辆实际行驶的轨迹作为监督信号让模型自己学会哪里能走。另一个是神经辐射场NeRF在可通行区域检测里的应用用多视角重建出三维场景从根本上绕开单应性矩阵的平面假设。这两个方向都还在早期但潜力很大。我个人在实际操作中的体会是可通行区域检测的难点从来不在网络结构而在数据质量和场景覆盖。一个简单的 U-Net配上足够多样、足够精细标注的数据往往比一个花哨的新网络配上粗糙数据要好得多。所以如果你刚开始做这个方向先把数据管线搭好把标注规范定清楚比急着换网络要重要得多。
锦
锦皓数字建站
深耕本土企业品牌数字化升级,专注原创端正雅致商务官网,从视觉设计到稳定运维全程保驾护航。