最近一段时间我把泊车语义建图算法从头到尾完整复现了一遍。这个课题听起来不大做起来才知道坑不少鱼眼图像的畸变校正、多相机视角下的BEV投影、像素级语义分割、栅格置信度更新每一步都能劝退一批人。我这次把整个复现过程的设计思路、关键代码、踩坑记录都整理出来给准备做自动泊车感知方向的同学一个可参考的样本。先说结论泊车语义建图算法拆开来看就是三件事。第一把环视鱼眼图像做语义分割得到每个像素的类别第二把分割结果投影到车辆周围的地面平面上得到鸟瞰视角下的语义图第三把多帧语义图按车辆运动信息融合到一张全局栅格地图里持续更新置信度。听起来不复杂真正做起来每一步的细节都能延伸出一大堆问题。这篇文章我尽量把每个关键决策背后的“为什么”讲清楚而不只是给一堆能跑的代码。1. 复现目标拆解泊车语义建图到底在做什么1.1 建图的输出对象一张带语义标签的鸟瞰栅格图先定义问题。泊车场景下的语义建图输入通常是车身四周的环视相机图像输出是车辆周围某个范围内、以车身坐标系为基准的栅格地图。每个栅格单元除了占据信息还带一个语义类别标签比如地面、停车位线、路沿、柱子、锥桶、动态行人等。这个定义很重要它直接决定了后续所有模块的设计方式。这里的关键词是“语义”。普通占据栅格只告诉你哪里是空的、哪里被占了但泊车场景里很多关键信息不是靠“占据”能表达的。停车位线贴在地面上从激光雷达点云角度看几乎不可见在栅格里它既不是障碍物也不是空白这时候必须靠视觉语义把“这是车位线”这个信息提出来。所以语义建图本质上是给几何地图叠加了一层人的先验知识让地图不仅能描述空间的物理占用还能描述空间的功能属性。输出形式我建议用0.05米/像素的分辨率。做车位检测时这个分辨率够用数据量也不大一个20米乘20米的地图也就400乘400个单元格单帧推理完全没压力。如果用更高的分辨率比如0.02米内存和计算量会明显上涨但对车位检测效果的提升很有限实时性反而受影响。这个分辨率的选择不是拍脑袋定的我前期做过几组对比实验0.05米和0.1米对车位角点定位误差的影响大概在5厘米以内但计算量差了好几倍所以0.05米是一个性价比最高的折中点。1.2 为什么不能只用纯几何建图纯几何建图比如基于激光雷达或单目深度估计的占据栅格在开放道路场景表现尚可但在泊车场景有两个硬伤。第一车位线无法被几何信息表达。车位线是地面上的白色标记高度几乎为零激光雷达的回波和深度估计都很难稳定捕捉。但自动泊车的核心任务就是识别车位、规划路径、泊入车位如果地图里没有车位线后面所有环节都成了无源之水。我见过有人尝试用高反色回波去提取车位线实测效果极不稳定稍微有点光照或磨损就丢了。第二泊车场景中需要区分的障碍物类型太多。一个矮路沿在几何上它是障碍物但实际上车可以骑过去一个悬空的树枝几何上也是障碍物但对泊车姿态没有影响。几何地图只给“占/空”二值信息无法表达这类语义差异。语义建图把“能不能通过”的判断交给了语义层比如栅格类别是“路沿”就放松碰撞检测栅格类别是“柱体”就严格避让这样比纯几何判断要可靠得多。我实际复现后最大的体会是语义信息和几何信息缺一不可。几何占据栅格提供空间约束语义标签提供属性解释两者融合之后才是一张真正可用的泊车地图。2. 整体方案选型与架构设计2.1 模块化路线为什么比端到端更稳关于整体架构我一开始也犹豫过要不要直接上端到端方案输入环视图像直接输出语义栅格图。后来还是放弃了原因有三个。第一端到端需要大量对齐标注数据。语义栅格图的真值需要把多相机图像和车辆位姿做离线融合再人工标注这个数据制作成本高得吓人个人开发者和小团队根本玩不转。模块化方案只需要每帧图像做像素级标注再利用已知的相机外参做几何变换数据的获取难度直接降了一个量级。第二端到端的可解释性差。复现过程中一旦结果不对你很难定位是特征提取的问题、注意力机制的问题还是位置编码的问题。模块化方案每个环节的输入输出都很明确哪一步出问题一眼就能看出来这对算法工程师排查问题来说是巨大的优势。第三模块化方案的每个环节都可以单独替换升级。语义分割网络可以换更强的后续的融合和车位提取逻辑不用动相机标定更精确了投影模块可以直接受益。这种可插拔的架构特别适合快速迭代。当然模块化方案的代价是环节之间的误差会累积。语义分割错了一个像素投影之后就错位标定矩阵偏差1个像素BEV图可能偏出十几厘米。这是模块化路线的固有缺陷只能通过每个环节把精度做足来弥补。整体上利大于弊所以最终架构定为标定模块、语义分割模块、BEV投影模块、栅格融合模块、车位后处理模块五个模块串成一条流水线。2.2 数据、硬件与工具链的准备复现这套算法需要的数据是环视图像序列加对应位姿。位姿信息用来做多帧融合可以从车辆的 odometry 或者惯性导航系统获得。如果没有实车条件可以用开源社区常见的数据集来代替至少包含鱼眼环视图像和车辆位姿真值帧率不低于10Hz场景最好覆盖地下车库、露天停车场、狭窄通道等典型泊车环境。硬件方面我用的是一台桌面级GPU显存8GB。这个显存级别跑轻量级语义分割网络绰绰有余后续如果要加更重的模型比如Transformer类建议上16GB以上显存。环视相机如果用低成本USB鱼眼模块做原型验证注意几路相机曝光参数尽量一致否则BEV融合时亮度差异会非常明显。工具链上我选的是PyTorch训练语义分割模型配合自定义C插件做栅格融合的实时推理。原型阶段全部用Python也可以但到实车部署阶段建议把投影和栅格更新这部分用C重写性能差距非常明显。标定工具我用的棋盘格加开源标定算法这部分下面专门讲。3. 核心模块细节解析每个关键步骤背后的为什么3.1 鱼眼相机标定这一步到底标的是什么鱼眼相机的标定是整套算法的地基。很多复现失败的项目最后追根溯源都死在标定这一关。标定要解决两件事一是内参二是外参。内参描述的是图像像素坐标与相机坐标系下光线方向之间的关系。普通相机可以用针孔模型近似但鱼眼相机的视场角超过180度存在严重的非线性畸变必须用专门的多项式畸变模型比如Kannala-Brandt模型来描述。这个模型的参数包括焦距、主点坐标以及畸变多项式的前几阶系数。标定的目标就是求出这些参数使得任意一个图像像素都能反投影出一条准确的光线方向。外参描述的是每个相机坐标系与车身坐标系之间的旋转和平移关系。四个环视相机分别装在车头、车尾、左右后视镜附近它们各自看到的是车子四周的一部分区域。要把四幅图像拼接成一张鸟瞰图必须知道每个相机相对车身的精确位姿。外参标定通常在水平地面上放置标定布或棋盘格通过多个视角的观测优化出旋转矩阵和平移向量。我在标定时拍摄了大约30张不同角度的棋盘格图片包含各个朝向和倾斜角度。角点检测全部成功的图大概有25张然后跑非线性优化重投影误差控制在0.15像素以内才算合格。一个容易被忽略的细节是标定时一定要把标定板完全铺平任何褶皱都会造成毫米级的误差投影到地面上就是厘米级的错位。最后我把标定结果生成了查找表LUT直接记录每个图像像素对应的地面网格坐标索引。这样在线运行时不需要每次都做复杂的畸变逆变换和坐标变换直接查表取数即可性能开销几乎可以忽略不计。这也是工程实践中的一个常用优化手段。3.2 语义分割的类别设计和模型选型语义分割是整个系统中信息量最大的模块。它的输出质量直接决定建图的准确性所以类别设计必须先想清楚。我使用的是六个类别:背景、地面、停车位线、路沿、柱体障碍物、动态目标。这六个类别的选择是有讲究的。背景类别用来吸收那些不关心的区域比如天空、远处墙面以及道路以外的部分。地面类别是BEV投影的主要来源因为只有地面的像素才能可靠地映射到俯视平面上。停车位线类别是全局地图的核心语义要素后续的车位检测完全依赖它。路沿类别用于启发式避让决策柱体障碍物用于不可通行区域标记动态目标类别用于短期占用记忆避免把移动物体残留到全局地图上。模型选型方面我一开始尝试过直接用通用的高精度分割网络推理速度确实不太行。后来换成了轻量级双向分割网络类似BiSeNet风格骨干网络采用窄体设计配合轻量级上下文聚合模块在保持精度可接受的前提下推理速度提升了接近三倍。最终模型在测试集上mIoU达到约87.6%其中停车位线类别的IoU是最低的这是所有分割任务里的典型难点因为车位线像素占比太小需要专门处理。训练细节上我使用了图像增强策略包括随机裁剪、缩放、色彩扰动和旋转。类别不平衡问题非常突出停车位线像素占比可能不到1%单纯用交叉熵损失效果很差。我最后的做法是主损失用交叉熵辅助损失用Dice系数对车位线类别施加更高的权重。训练轮次大约跑了80个epochbatch size为16初始学习率0.02配合余弦退火调度。训练过程的损失曲线如果长时间平台期不下降优先检查数据标注有没有错标漏标。3.3 从图像到车身系鱼眼图像的BEV投影BEV投影是把分裂的图像像素集中到同一空间坐标系下的关键操作。因为路面可以近似看作一个平面图像中的每个地面像素理论上都可以通过已知的相机内外参数映射到车体周围的一个具体位置。具体做法是这样先利用内参矩阵和畸变模型把鱼眼图像中的像素点反投影成一条光线然后求这条光线与地面平面的交点最后把交点坐标变换到车身坐标系。这样每个像素都能得到它在车体坐标系里的对应位置。把所有像素的语义标签映射过去就得到了一幅车身周围的语义鸟瞰图。实际实现时我没有在推理阶段实时做上述计算而是预生成一张映射表记录每个像素对应的地面网格索引。以四路相机为例每路相机负责车身一侧每一帧只需要做四次查表然后以索引为凭据把对应位置的语义分数累加到栅格图上速度快而且实现简单。一个工程上的难点是多相机重叠区域的处理。四路相机的视野在车身四角必然有重叠同一个地面点在两幅图像里都可能出现但两个像素的颜色和语义置信度可能不一样。我的做法是按照相机光心到该地面点的距离做加权融合距离越近的相机权重越高这样重叠区域过渡平滑不会出现明显的拼接缝。实测下来这个权重方案比简单的平均融合能进一步降低误检率。3.4 多帧融合对数几率栅格更新单帧的BEV语义图噪声很大近距离还好远一点的位置置信度低而且会被车体自身遮挡。多帧融合就是为了解决这个问题用车辆运动信息把历史栅格对齐到当前车身坐标系然后逐帧更新每个栅格的置信度。我采用的是标准的对数几率栅格更新法。每个栅格维护一个对数几率值数值大于零表示该栅格更可能被占据小于零表示更可能是空闲的。观测到一帧新数据后更新公式为当前对数几率等于历史对数几率加本次观测对数几率减去初始先验对数几率。初始先验一般设为0也就是每个栅格初始状态下的占据概率是0.5。如何将某个栅格的语义观测转换为对数几率呢需要把每个类别的置信度映射成对应占据概率。比如语义分割识别出该像素是地面那么就认为这个栅格是空闲占据概率较低如果是柱体障碍物就认为占据概率很高如果是停车位线那么占据概率中等偏低但类别直接记录为车位线。这样几何占据和语义类别是两套挂在一起的属性融合时一并更新。更新时还必须把车辆自身当前所占用的区域强制设置为空闲否则车体下方的残留阻碍物会把地图污染掉。这部分我用一个简单的矩形区域将车体网格的占用概率清零。另外对移动目标类别我会额外加入一个短期遗忘机制如果连续多帧在一个位置观察不到动态目标就把对应栅格的动态类别置信度逐步衰减。否则停车场里一辆经过的车会在全局地图上留下一条长长的“尾巴”。4. 实操流程从零复现泊车语义建图4.1 环境准备与依赖安装实操的环境我用的是Python配合PyTorch核心依赖包括OpenCV图像处理和标定、NumPy矩阵运算、PyTorch模型训练以及TensorBoard训练可视化。GPU加速跑PyTorch是必须条件纯CPU训练一个分割模型会让等待时间变长很多。我习惯用一个独立的虚拟环境来管理依赖。安装的时候有一个经验先把PyTorch装好再装其他依赖包否则后续安装过程可能会强制更改PyTorch的版本导致已经写的训练代码出现兼容性问题。具体版本方面Python用3.9PyTorch用2.0以上OpenCV用4.7以上这几个版本组合当前非常主流。4.2 相机标定实操记录标定内容分两个阶段内参标定和外参标定。内参标定我用棋盘格完成。棋盘格贴在平整硬板上图像采集时让棋盘格在视野内不同距离、不同角度出现尽量不要出画面边缘。将采集到的图像输入标定算法它自动提取角点并优化内参模型最终输出焦距、主点坐标和畸变系数。外参标定的目标是让四路相机形成统一的俯视拼接效果。我的方法是把车停在一个空旷平面上在车辆四周地面铺设大尺寸标定布上面有清晰的网格图案利用已知的网格位置和角点观测来估计各路相机到车身的变换。标定布必须铺得完全平整四个角用重物压实。这个过程我迭代了三轮才对好前两轮都是因为标定布有轻微褶皱导致拼接处出现错位。标定完成后我验证了一下对位效果把车开到一块方砖地面上观察BEV俯视图里地砖缝隙是否对齐成一条直线。如果可以的话说明外参精度已经足够可靠。这一步做完整个流水线都顺畅起来。4.3 语义分割模型训练与推理训练语义分割模型时我先把图像缩放到统一的尺寸比如输入分辨率设为512×512然后送入轻量级骨干网络提取特征最后通过几层上采样把特征分辨率恢复到输入尺寸输出每个像素的类别概率。训练用的损失函数是加权交叉熵加Dice损失。权重根据类别像素占比动态生成车位线类别权重设到最高地面类别权重相对低一些。优化器使用带动量的随机梯度下降动量系数0.9权重衰减1e-3初始学习率0.002采用多项式衰减策略。另一个实用的训练经验是启用混合精度训练显存占用能减少三分之一速度也有明显提升精度几乎没有损失。推理阶段我把模型导出为接口更轻量的部署格式这样在运行时只需要一次前向传播就可以拿到每路相机的分割结果。推理速度在桌面级GPU上可以达到每帧约20毫秒也就是50帧每秒足以满足泊车的实时性要求。4.4 语义栅格建图与车位提取建图模块我维护一个全局栅格地图包含占据对数几率值和语义类别计数两部分。每次收到新帧先根据当前的车辆位姿把历史地图变换到当前帧的车身坐标系下再把当前帧的BEV语义观测叠加进去。地图范围设定为车身前后左右各10米分辨率0.05米。多帧融合的核心代码如下逻辑很简单但性能很好def update_grid(grid, weight, sem, obs_probs, x_idx, y_idx): # 对数几率更新 grid[y_idx, x_idx] obs_probs - grid_prior # 语义类别计数 sem[y_idx, x_idx, sem_class] weight由于我使用了预生成的索引映射每个像素都直接映射到对应网格单元更新过程就是一次累加操作性能开销极低。车辆触地矩形区域内的网格每帧都强制重置为空闲避免把车身底下误建模成障碍物。从语义栅格提取车位时我用连通域分析和矩形拟合来做。首先把车位线类别的概率图二值化再用形态学闭运算把断开的线段连接起来然后标记连通域对每个域拟合最小外接矩形再根据矩形长宽比筛选车位候选框。这里有个细节真实车位通常是双线或单线构成的矩形矩形内部是地面因此我先对内部区域做二次判断要求内部大部分像素语义类别是地面这样可以过滤掉大量误检。4.5 评估指标与可视化评估语义建图效果不能只看分割精度还要看最终车位检测的性能。我的评估分为三个层面语义分割精度、车位检测召回率、车位角点定位误差。语义分割精度用mIoU衡量这个数值反映了像素级语义分割的整体质量。车位检测召回率用于评价从语义栅格中提取车位的完整性一个车位被漏掉就意味着泊车任务彻底失败所以召回率的优先级比精确率更高。车位角点定位误差表示检测到的车位角点与真值角点在车身坐标系下的距离误差这个指标直接关系到后续路径规划能否精确泊入。我把这三项指标都打印出来对照检查任何一个指标异常下降都提示对应模块有问题。可视化我也做了建图过程中实时渲染栅格图叠加在实时视频上用颜色区分各类别有问题的地方一眼能看到这在调试阶段救了我很多次。5. 常见问题与排查技巧实录5.1 鱼眼图像边缘畸变导致BEV图严重变形复现过程中最常遇到的视觉异常是BEV图在地面远处区域被拉伸得不成比例严重时甚至出现“一根斜线在图像边缘被拉成弧形”的现象。原因通常是畸变校正精度不够或者部分图像处于鱼眼镜头极端边缘区域。排查方法是打印投影前后的关键点坐标对比图像中已知距离的两点在BEV图里的像素距离是否一致。如果发现远端的畸变格外严重优先重新做内参标定增加边缘区域的标定板采集数量如果标定效果正常就要考虑对每个像素映射时是否用了正确的畸变逆变换这一块最容易踩坑。5.2 多相机重叠区域出现重影重影的表现是地面上的同一个车位线或路沿在BEV图里变成了两条前后错开的影子。这几乎可以断定是外参标定或重叠区权重的问题。我的排查顺序是先检查外参标定是否准确把重叠区域的对应点人工标出来看看差异大小然后检查重叠区权重是否正确生效确认不是简单平均导致的边缘偏色和位置偏移。如果外参没问题但重叠区两侧语义置信度差异很大权重融合会偏向置信度高的相机也会产生轻微的拼接痕迹此时可以尝试扩大重叠区的渐变权重范围。5.3 栅格地图坐标系漂移多帧融合时如果全局地图边建边走原本闭合的车位轮廓慢慢裂开说明车辆位姿的累计误差在明显累积。这在高频运动、频繁转向的场景下非常常见。排查时先在原地做静态建图测试确认不发生漂移后就锁定为位姿问题。解决的常规方案是提高位姿更新频率并加入闭环检测来修正累计误差。泊车场景本身是个小范围慢速场景漂移不会像室内机器人那样严重但也不能完全忽视。5.4 车位线在语义图中断裂车位线断裂是最让人头疼的问题之一车位线本来就细再加上鱼眼镜头暗角、强光反射、遮挡等因素分割输出的线常常断成好几段。我经历过“停车场绕了一圈几乎所有车位都被判成不可用”的尴尬。断裂的直接原因是语义分割对车位线的召回不够。我的解法不是盲目加大模型容量而是做两件事第一在BEV融合阶段对车位线类别引入邻域投票机制一个栅格如果周围八个邻居里有多个被判定为车位线就增加它自己的车位线置信度第二在后处理阶段做形态学闭运算用结构性元素让断裂的线段连接起来。这两招配合车位线断裂的问题明显缓解。5.5 实时性能不达标怎么办性能问题是工程落地的老难题。我最初纯Python实现整条流水线时建图部分耗时占了很大比例。后来做了三个关键优化投影用预生成映射表栅格更新用矩阵批量操作多相机并行处理。优化后整条流水线耗时降低到原来的三分之一。如果还想进一步压缩推理耗时推荐把建图模块用更低层语言重写并在关键循环里做并行化加速。我用了一个简单的经验法则如果整个系统耗时超过100毫秒先看建图部分有没有可以向量化的循环如果循环里存在大量重复的坐标变换计算就考虑预计算那些不变的量。我个人在实际操作中的体会是复现这类算法最大的陷阱不是理论难度高而是工程细节满天飞。一个标定参数没调准、一个权重写反都会让最终效果和预期相差十万八千里。但只要把模块边界划清楚每步都验证输入输出整个系统是完全可以稳定跑起来的。最后再分享一个小技巧全程保留每一轮实验的配置和日志不仅方便对比更能在某天突然发现新问题时快速知道是最新改动引起的还是历史遗留的问题。这套语义建图的流水线搭建好后后续还可以继续扩展语义类别、加入多传感器融合核心架构不需要做太大改动。