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，配上足够多样、足够精细标注的数据，往往比一个花哨的新网络配上粗糙数据要好得多。所以如果你刚开始做这个方向，先把数据管线搭好，把标注规范定清楚，比急着换网络要重要得多。
