自动泊车和代客泊车AVP这两年越来越卷真正下过地库、跑过实车的人应该都有感触视觉感知才是整个系统里最容易翻车的环节。车位能不能稳定检出、地锁和锥桶会不会漏掉、地面箭头和减速带能不能看清这些细碎问题做不好停车场再智能也白搭。这篇博文就以“基于目标检测模型的停车位检测、低矮障碍物、地面标识检测”为线索完整聊聊我从方案选型、数据标注到模型训练、部署实测的整套落地经验重点讲清楚这类任务和常规通用检测到底差在哪以及为什么现在大家都在追macs仅5MB的轻量化目标检测模型。内容适合正在做自动泊车感知、智慧停车场改造或者想入手边缘端检测项目的朋友直接照着参考就行。1. 场景拆解三个任务为什么必须放在一个模型里做很多第一次接触这个需求的人都会问停车位检测、低矮障碍物、地面标识本来是三件事各自拿一个专用模型不好吗答案是理论上可以工程上不行。1.1 三种目标的本质差异与检测难度停车位检测的目标是车位线、车位入口和可用空位本质上是“线状”和“区域”的组合很多方案还会引入分割模型先提取车位线再拟合角点。低矮障碍物则截然不同它们是地锁、锥桶、石墩、消防栓、减速带这类立体小物体高度通常低于40厘米在图像里占的像素很少。地面标识又是另一类箭头、文字、停止线、网格线都是“平面符号”本身没有物理高度全靠颜色和边缘对比度区分。放到同一个模型里意味着同一个特征提取网络要同时适应三类差异极大的目标形态。经过实测多任务共享主干在车位这类结构特征明显、地面标识这类纹理特征明显、低矮障碍物这类深度轮廓特征明显的目标上特征冲突并不大反而由于共享了底层的边缘、纹理、颜色特征整体泛化能力比三个独立模型更稳。1.2 感知任务在自动泊车链路中的位置在真实的自动泊车链路里感知通常分两路环视鱼眼摄像头负责近距离、低速场景前视或侧视摄像头负责远距离预判。停车位检测、低矮障碍物、地面标识检测恰恰横跨这两路输入。环视图像中停车位和低矮障碍物是泊车入位的关键输入车能不能安全停进车位就看这两类检得准不准前视图像中地面标识和远距离障碍物是路径规划的关键输入车辆需要提前判断前方是否有减速带、禁停区域或障碍物。把三类任务统一到一个检测模型里节省了计算资源和内存占用还避免了多模型串联带来的延迟叠加这对强调实时性的车载平台尤为重要。注意如果你只做停车位检测可以不考虑低矮障碍物但如果你做的是完整泊车系统这两者必须同时存在否则“检测到空车位但车里藏着地锁”这种致命场景就拦不住。2. 模型选型与轻量化路线5MB模型是怎么炼成的目标检测模型这几年迭代非常快YOLO系列从v5一路卷到v11还有RT-DETR这类Transformer结构外加各种轻量主干。但落到车载嵌入式平台约束条件远比刷榜要苛刻。2.1 从YOLO到轻量化模型选型对比我最早在这个项目里用的是YOLOv5s在3080显卡上训练测下来mAP有0.87左右看起来很漂亮。但一部署到车规级平台问题就来了单帧推理时间接近120毫秒内存占用超过400MB前端摄像头和环视摄像头同时跑两个模型直接压垮了调度器。后来我系统对比了几条路线模型方案参数量输入尺寸推理耗时边缘平台车位mAP障碍物mAP地面标识mAPYOLOv5s7.2M640x640120ms0.890.830.91YOLOv8n3.2M640x64085ms0.860.780.89RT-DETR-tiny4.0M640x640140ms0.840.760.87轻量化剪枝蒸馏0.8M512x51232ms0.820.750.85最终我选择的路线是以YOLOv8n为基线做结构化剪枝结合蒸馏把模型压到0.8M参数量、约5MB的权重文件换来边缘平台上32毫秒的推理速度。2.2 通道剪枝、量化与蒸馏的组合拳5MB目标检测模型绝不是凭空冒出来的核心手段有三步第一步通道剪枝。对YOLOv8n的每个卷积层计算BN层缩放因子的L1范数把贡献小的通道直接剪掉。这一步要控制剪枝比例建议从30%开始逐步增加到50%剪得太猛会导致mAP断崖式下跌。我在三类目标上实测剪枝50%后mAP平均掉了0.04但推理速度提升了近一倍。第二步知识蒸馏。用原版YOLOv8n作为教师模型让轻量化学生模型去模仿教师的特征图输出和预测分布。这一步对恢复剪枝掉精度非常有效尤其对低矮障碍物这类小目标蒸馏比单纯重新训练能高出3-5个百分点的mAP。第三步INT8量化。模型训练完成后用校准集做INT8量化这一步几乎不损失精度但能进一步压缩模型体积并加速推理。实际操作中5MB的模型文件就是剪枝后FP16权重再做INT8量化得到的结果。2.3 输入分辨率与算力权衡模型轻量化只是把“同样的事做得更快”真正影响检测效果的上限是输入分辨率。地面标识中的文字和箭头在远距离下只占十几个像素分辨率太低基本无解。我做过一组对照测试输入640x640时5米外的地面箭头识别率约85%降到416x416后直接跌到65%。对停车位线和低矮障碍物也有影响但远没有地面标识那么敏感。最终的工程取舍是前视摄像头采用576x576输入环视摄像头采用512x512输入既保证小目标的召回率又控制整体计算量。你如果算力特别紧张可以保留640x640给地面标识专用分支其余任务共享轻量特征但对大多数项目来说576已经够用。3. 数据标注与训练细节三类任务的脏活累活模型结构只是骨架数据才是血肉。这个项目的难点不在于网络结构多新颖而在于数据标注标准和训练细节上稍不注意就会踩坑。3.1 停车位标注垂直、平行、斜列的标准不统一停车位标注看起来简单把车位线框出来就行实际上远不是这样。垂直车位和斜列车位的消失点不同平行车位的车位线往往只有前后两条短线侧向没有线。如果标注框只是简单框住两条线的区域模型学到的其实是“一片空地的边缘”而不是“一个可以停车的位置”。我的标注规范是对垂直和斜列车位标注框覆盖整个车位区域同时单独增加一个角点类别标记入口线的两个端点对平行车位标注框以前后两条短线的中心连线为基准框体略向内收避免把相邻车位的空间也框进来。训练时还需要额外监督角点与框的匹配关系这样模型才能学到“车位不仅是一块区域还必须存在可进入的开口”。3.2 低矮障碍物的边界定义与标注细节低矮障碍物是最难统一标注标准的类别。地锁、锥桶、石墩、消防栓、减速带形态差异极大遮挡情况也各不相同。最开始我把所有低于车身高度的物体都归为“障碍物”训练出来的模型经常把地面上的窨井盖、树影也当成障碍物。后来我把类别拆分得更细地锁单独一类带反光条的锥桶单独一类固定石墩单独一类减速带单独一类其他低矮物体归为通用障碍物。这个调整非常有效地锁的召回率从70%左右提升到90%以上误检率也直线下降。标注框还有一个细节低矮障碍物要贴着地面标注不要包进整个物体的三维空间。模型根据检测框底边位置估算距离如果框的上沿包含了太多天空背景底边位置会被抬高导致测距偏大。3.3 地面标识的易混淆问题箭头、文字、停止线地面标识类别比较少就画箭头、文字、停止线、禁停网格、减速带标识这几种但误检率反而是三个任务里最高的。原因是地库里光线复杂不同材质地面反射不同同样一个左转箭头在环氧地坪和水泥地上呈现的特征差异极大。为了防止模型学偏我把训练集中的每一张地面标识图都做了精细清洗。比如左转箭头和直行箭头的区别只在箭头的折角标注框要精确贴合箭头边缘文字类标识只保留完整文字块半个字或磨损严重的样本直接剔除。因为地面标识在图像中往往是透视畸变的我还专门对标注掩膜做了透视矫正让每个箭头都恢复成近似的正视角形状这个操作大幅减少了类别混淆。3.4 数据增强与样本平衡的实战策略三类目标天然存在严重的不平衡一个地库里可用的标准车位可能上千个但地锁只有几十个地面箭头更是几场才出现一个。如果不做平衡模型训练会被车位样本带偏。我的处理方法是先按类别计算数量对低矮障碍物和地面标识做马赛克增强和复制粘贴增强每个训练epoch随机复制这些稀有类别的实例到其他图像中。复制时要注意透视变换和光照匹配否则模型学到的是“贴图感”到了真实场景反而检测不到。此外由于地库普遍光线暗、逆光场景多我将训练集的曝光度、色温、噪声模拟做了大幅随机化还加入了模拟雨天反光的贴纸增强。测试下来这一套增强让模型在下雨天和早晚高峰逆光场景的鲁棒性明显提高。4. 模型训练与部署实测从数据集到边缘平台这一节重点说训练配置和部署环节的实操细节包括损失函数设置、训练超参选择以及最终在边缘平台上跑出来的真实数据。4.1 损失函数与训练超参配置多类别检测任务损失函数主要由三部分组成分类损失、框回归损失和置信度损失。YOLOv8默认使用BCEWithLogitsLoss处理分类CIoU处理框回归。我在实际训练时做了一处关键调整针对低矮障碍物这类小目标把框回归损失换成了面向旋转框的变体同时将小目标的权重乘了1.5倍这相当于告诉模型“宁可错杀、不可漏检”对后续避障非常关键。训练超参方面我最常用的是一套通用配置超参数数值说明输入尺寸576x576兼顾小目标和计算量batch size64显存不够就用梯度累积epoch300配合早停一般180轮收敛初始学习率0.01用warmup余弦退火数据增强mosaic 1.0 mixup 0.2小目标增强开启类别权重车位1.0 / 障碍物1.5 / 标识1.2平衡不平衡样本4.2 训练过程中的精度监控训练过程不能只盯着全局mAP看三类任务要分开盯。全局mAP由车位拉高掩盖了地面标识或障碍物的短板最后部署时才暴露问题代价就大了。我在训练脚本里加了一个自定义评估函数每5个epoch在验证集上分别计算三类目标的mAP和Recall。当车位mAP已经到0.9而低矮障碍物还在0.6徘徊时我会先查是不是样本量太少再查是不是增强策略不对。有一次障碍物mAP迟迟上不去排查后发现是标注框不规范大量地锁标注框把连接臂也算进去了模型一直没分清地锁和地面投影重新清理数据后一轮就涨了5个点。4.3 边缘平台上的部署与推理优化模型训练好并不代表能用。真正上车或上边缘盒子后还有几个关键优化要做。首先是把ONNX导出后做算子融合和nms优化。NMS非极大值抑制在CPU上经常成为瓶颈我用的策略是引入一个轻量级的解耦NMS模块将不同类别的目标分开做抑制再把置信度阈值调高到0.45单帧NMS耗时从8ms降到2ms。其次是动态shape静态化。车载平台普遍对动态shape支持不好推理时频繁重分配内存。我把模型输入固定为576x576使用静态shape推理实测FPS比动态shape提升了10%以上。最终在边缘平台上得到的实测数据如下INT8量化后的模型文件约5MB单帧推理时间32ms内存占用约180MB稳定跑30FPS。三类目标综合mAP为0.82其中停车位mAP 0.85、低矮障碍物mAP 0.75、地面标识mAP 0.83符合整个项目“人可接受、车可执行”的基本要求。5. 常见问题与排查技巧实录这个项目踩过的坑和总结出的排查方法比训练本身的容量还大整理几个最有代表性的。5.1 停车位误检把地锁、车轮也当成了车位最常见的问题是车位检测把地锁、车轮、甚至地面的阴影误判为可停区域。原因有两个一是训练样本中“空车位地锁”的负样本太少模型只看到了车位线和整洁地面没学会“车位里有东西就不算空位”二是停车位标注框太宽包含了相邻车位的边缘。解决方案有三个方向一是增加大量“有人停车位和破损车位”的负样本专门标注车位的不可用状态二是在车位检测分支上增加一个语义分割辅助头让模型学会区分车位区域内的“地面”和“非地面”三是后处理规则如果检测框内同时出现低矮障碍物或车辆目标则判定该车位不可用。第三种方案最简单直接也是我最终采用的。5.2 低矮障碍物漏检暗光、反光和低对比度是元凶低矮障碍物的漏检高发场景集中在地下车库的暗光区域和环氧地坪的反光区。地锁本身颜色暗又紧贴地面在夜间几乎和背景融为一体。YOLO这类anchor-based模型对10x10像素以下的目标非常不敏感这是结构决定的靠换模型很难根治。我的排查步骤是先统计漏检目标的尺寸分布。如果大量漏检目标在20x20像素以下优先做两件事一是提升输入分辨率从512改成576或640二是加“小目标增强”策略在数据增强阶段把目标随机等比缩小后再粘贴到大图中强制模型学习小尺寸特征。如果漏检目标尺寸分布正常那就是对比度问题增加CLAHE自适应直方图均衡化的预处理或者引入融合红外通道的双目输入也能明显改善。5.3 地面标识误检强烈建议加区域约束地面标识类的误检基本都发生在非泊车区域比如车道中央的杂物、地面积水反光等。单纯加数据效果有限因为背景变化太丰富永远收集不完。更好的办法是从部署层面加“区域约束”结合车道线检测或语义分割先划分出“可行驶区域”和“疑似标识区域”然后只在这些区域内做地面标识的检测后处理。这个方法听起来简单实际效果却比任何数据增强都显著。原因是地面标识在物理世界里本身就是有明确位置边界的箭头和停止线只会出现在特定区域模型如果出现“在墙上检出一个左转箭头”这种离谱输出区域约束直接就能把它过滤掉。我在项目中引入了一个极简的地面分割分支输出32x32的低分辨率地面掩码再做目标过滤误检率从7%降到了2%以内。6. 算力搭台与后续扩展方向项目的核心已经跑通但距离一个成熟产品还有不少路。基于目前这套基线和摸索出的方法论后续还有几个值得投入的方向。6.1 传感器融合与多视角拼接单摄像头检测在遮挡场景下很难突破车位被旁边车挡住、地锁被车尾挡住都是常事。下一步可以引入环视系统的多摄像头拼接将四个鱼眼镜头的检测结果投影到统一的世界坐标系做跨视角融合。具体做法是把每个摄像头检测到的车位角点和障碍物底边通过外参投影到鸟瞰图用匈牙利匹配做跨镜跟踪这样即便某个视角被遮挡其他视角仍能给出有效目标。6.2 时序信息与运动预测当前模型是单帧检测对静态图像处理没问题但在车辆缓行过程中容易出现抖动和跳变。引入时序信息后可以用一个轻量级的跟踪器对车位和障碍物做短时跟踪保持检测结果的连续性。还可以结合IMU进行运动补偿降低车辆颠簸带来的检测框抖動。这个扩展对AVP场景尤其重要车辆在倒车入库过程中需要稳定跟踪后方的地锁和限位器单帧检测做不到这种连续稳定。6.3 自监督与增量学习停车场场景千差万别新商场的车位线和标识风格可能完全不同于训练集。手动打标成本太高可以用自监督方式先做预训练把大量未标注的地库图像丢给模型做对比学习让模型先学会区分“这是地库、这是室外停车场、这是水泥地面”再在少量标注数据上微调能显著减少新场景的适配成本。增量学习则让模型在部署后持续学习新发现的车位样式但要注意防止灾难性遗忘我建议用经验回放结合正则约束的方式。如果有人问我这个项目做过最值的事是什么我会说是把停车位、低矮障碍物和地面标识这三个任务真正揉进了同一个轻量模型里并且验证了它在真车环境下的可行性。过程中的坑很多但每解决一个对整个泊车感知链路的理解就更深一层。最后分享一个小技巧无论模型结构怎么换一定要在项目最开始就把验证集按场景分层建好否则后面调模型会一直在原地打转因为你是凭感觉判断好坏而不是用数据。