简介这是一套面向计算机视觉与智能交通方向的车辆辅助驾驶系统项目资料适合人工智能、通信工程、自动化、电子信息等专业的在校学生、教师及企业技术人员用于毕业设计、课程设计或项目立项演示。资源围绕路面分析、交通路况识别与辅助驾驶展开包含完整源码与详细文档代码经过测试可正常运行并已通过导师评审与答辩获得95分评价。压缩包共110个文件约9.88MB以48个C头文件、24个cpp源文件为核心实现辅以txt说明、xml配置、md文档及少量图片与脚本涵盖JSON解析、HTTP通信、模型配置等模块目录结构清晰便于按功能检索与二次开发。目前已有46人学习关注。读者可据此掌握从图像处理到路况识别的完整实现思路理解工程化代码组织方式并在此基础上修改扩展功能快速完成毕设、课设或作业任务。1. 路面分析 交通路况识别一套车辆辅助驾驶系统到底在做什么很多人第一次听到「车辆辅助驾驶系统」这个词脑子里浮现的是激光雷达、高精地图、域控制器这些贵得离谱的东西。但如果你把预算压到几百块、算力压到一块入门级 GPU 甚至 CPU还想让车「看懂路」那能依靠的就只剩计算机视觉这一条路。这套方案要解决的核心问题很具体用摄像头拍到的画面判断前方路面有没有坑洼裂缝、车道线还在不在、前面有没有车和行人、当前路况是畅通还是拥堵最后把这些结论汇总成一个能提示驾驶员的信号。它适合谁适合做计算机视觉大作业的学生、想入门辅助驾驶的嵌入式工程师、以及手里只有普通摄像头和一台笔记本、想先把整条链路跑通再谈优化的开发者。路面分析和交通路况识别这两件事一个管「路好不好」一个管「周围什么情况」合起来才是辅助驾驶该有的感知底座。2. 从一帧图像到驾驶提示整条视觉链路的拆解2.1 为什么不能一个模型包打天下刚上手的人最容易犯的错是想着训练一个「万能模型」输入一张图直接输出「前方有坑、左边有车、路况拥堵」。这个思路在 demo 阶段看着很美一上真实数据就翻车。原因在于路面分析和交通路况识别对图像特征的需求根本不一样。路面病害检测看的是纹理和灰度突变坑洼边缘、裂缝走向这些细节在浅层特征里最明显网络不需要太深而车辆、行人、交通标志的识别依赖语义级别的形状和上下文需要更深的骨干网络和更大的感受野。把两者塞进一个头梯度会互相打架最后两边都不精。常见做法是拆成两条并行的分支共享一个轻量骨干做特征提取然后各自接检测头。骨干可以用 MobileNetV3 或者 ShuffleNetV2参数量小、推理快适合辅助驾驶这种对延迟敏感的场景。路面分支接一个分割头输出像素级的病害区域掩码交通目标分支接一个检测头输出车辆、行人、交通灯的边界框和类别。两条分支在训练时可以分别设不同的学习率路面分支收敛快学习率调小一点防止过拟合。这里有个选型上的取舍要讲清楚如果你只是做课程项目或者验证可行性完全可以用两个独立模型分别跑省去共享骨干的联调麻烦。共享骨干的价值在于省算力但代价是训练时两条分支的 batch 组织、损失权重都要仔细调新手很容易在这里卡住。我一般建议先用两个独立模型把效果跑出来确认数据管线和评估指标没问题再考虑合并。2.2 数据从哪来怎么标这套系统最耗时间的不是写模型是搞数据。路面病害的公开数据集不多常见的有 CrackForest、RDD2022 这类主要覆盖裂缝坑洼的样本偏少。交通目标检测可以用 BDD100K、KITTI 或者国内的一些路测数据集。但真实项目里公开数据集只能当预训练用最终还是要自己采。采集设备就是普通行车记录仪或者手机固定在挡风玻璃后分辨率 1080P 足够帧率 30fps 采视频后期抽帧。抽帧策略要注意连续帧之间差异很小全抽会导致大量冗余样本模型见过多相似图会过拟合。我一般按每秒抽 2 到 3 帧遇到弯道、颠簸路段加密抽。标注工具用 LabelImg 标检测框用 LabelMe 标分割掩码导出格式统一成 COCO 或者 YOLO 格式。标注规范必须提前定死否则后面返工能让人崩溃。路面病害的边界怎么算裂缝的起止点在哪坑洼的轮廓要不要包含边缘的碎裂区这些都要写进标注手册让所有标注人员对齐。交通目标那边遮挡超过 50% 的车辆标不标、远处小于 20 像素的行人标不标也要有明确规则。血泪经验是标注规范没定好就开工标到一半发现标准不一致几千张图全部重标。2.3 最小可跑通的训练脚本下面这段代码是一个双分支模型的训练骨架用 PyTorch 写骨干共享两个头分别输出分割和检测结果。这不是完整工程但能让你看清数据怎么流、损失怎么组。import torch import torch.nn as nn import torchvision.models as models class SharedBackbone(nn.Module): def __init__(self): super().__init__() # 用 MobileNetV3 做骨干取前几层特征 mobilenet models.mobilenet_v3_small(pretrainedTrue) self.features mobilenet.features # 输出通道 576 self.out_channels 576 def forward(self, x): return self.features(x) class RoadSegHead(nn.Module): def __init__(self, in_ch, num_classes2): super().__init__() # 简单上采样分割头num_classes2 表示背景和病害 self.conv nn.Sequential( nn.Conv2d(in_ch, 256, 3, padding1), nn.BatchNorm2d(256), nn.ReLU(inplaceTrue), nn.Conv2d(256, num_classes, 1) ) def forward(self, x): x self.conv(x) # 双线性上采样回输入尺寸 return nn.functional.interpolate(x, scale_factor32, modebilinear, align_cornersFalse) class TrafficDetHead(nn.Module): def __init__(self, in_ch, num_anchors3, num_classes4): super().__init__() # 检测头输出每个 anchor 的类别和框偏移 self.num_anchors num_anchors self.num_classes num_classes self.conv nn.Conv2d(in_ch, num_anchors * (num_classes 5), 1) def forward(self, x): return self.conv(x) class AuxDrivingNet(nn.Module): def __init__(self): super().__init__() self.backbone SharedBackbone() self.seg_head RoadSegHead(self.backbone.out_channels) self.det_head TrafficDetHead(self.backbone.out_channels) def forward(self, x): feat self.backbone(x) seg_out self.seg_head(feat) det_out self.det_head(feat) return seg_out, det_out # 损失组合分割用交叉熵检测用简化版多任务损失 def compute_loss(seg_pred, seg_gt, det_pred, det_gt): seg_loss nn.functional.cross_entropy(seg_pred, seg_gt) # det_gt 这里假设已经编码成偏移和类别实际项目要接完整检测损失 det_loss nn.functional.mse_loss(det_pred, det_gt) return seg_loss 0.5 * det_loss # 权重 0.5 是经验值可调这段代码的关键点有三个。第一骨干用的是mobilenet_v3_small的features部分输出通道 576特征图尺寸是输入的 1/32所以分割头里用scale_factor32上采样回去。第二分割头输出 2 类背景和病害实际项目里病害可以再细分裂缝、坑洼、修补改num_classes就行。第三检测头这里简化成了直接回归真实项目要换成 anchor-based 或者 anchor-free 的完整检测损失比如 FCOS 或者 YOLO 的损失函数。损失权重 0.5 是我在几个数据集上试出来的起点分割损失通常比检测损失大一个量级不加权检测分支会被淹没。参数上要调的学习率初始设 1e-3用余弦退火batch size 根据显存来1080P 输入下 8 到 16 比较稳训练轮数看数据量一万张图大概 50 到 80 轮收敛。如果分割结果边缘毛糙把分割头的卷积核从 3 换成 5感受野大一点会好。3. 路面病害检测从裂缝到坑洼的像素级判断3.1 分割比检测更适合路面分析的原因路面病害有个特点形状不规则、边界模糊、大小差异极大。一条细裂缝可能只占几个像素宽一个坑洼可能横跨半个车道。用目标检测框去框这些东西框里大量是背景像素回归出来的框要么太松要么太紧评估指标 IoU 很难看。分割是逐像素分类裂缝的细长结构、坑洼的不规则轮廓都能保留后续算病害面积、严重程度也直接基于像素统计更合理。但分割的代价是标注成本高。检测框画个矩形就行分割要沿边界描点。折中方案是先用检测框粗标再在框内做弱监督分割或者用 SAM 这类分割大模型辅助生成掩码再人工修。我一般建议课程项目直接用分割标注量控制在两千张以内配合数据增强也能出效果。3.2 类别不平衡怎么处理路面图像里病害像素占比通常不到 5%背景占 95% 以上。直接训练模型会倾向于全预测背景准确率看着 95% 很高实际一个病害都没检出来。这是分割任务里最经典的坑。处理办法有几个。一是损失函数用 Dice Loss 或者 Focal LossDice 直接优化预测和真值的重叠度对类别不平衡不敏感Focal Loss 降低易分类样本的权重让模型关注难样本。二是采样时保证每个 batch 里至少有几张含病害的图别让整个 batch 全是好路。三是后处理时对病害类别的概率图做阈值调整背景阈值设 0.5病害阈值可以降到 0.3宁可误检不可漏检辅助驾驶场景漏检代价更大。# Dice Loss 实现用于路面分割 class DiceLoss(nn.Module): def __init__(self, smooth1.0): super().__init__() self.smooth smooth def forward(self, pred, target): # pred: [B, C, H, W] logits, target: [B, H, W] 类别索引 pred torch.softmax(pred, dim1) # 只取病害类别假设索引为 1 pred_disease pred[:, 1, :, :] target_disease (target 1).float() intersection (pred_disease * target_disease).sum() union pred_disease.sum() target_disease.sum() dice (2. * intersection self.smooth) / (union self.smooth) return 1 - dice这个 Dice Loss 只对病害类别算背景不参与直接绕开不平衡问题。smooth是防止分母为零的平滑项设 1.0 就行。实际训练时我会把 Dice Loss 和交叉熵按 1:1 加权组合交叉熵提供稳定的梯度Dice 负责拉高重叠度。3.3 推理阶段的滑窗与拼接路面图像分辨率高直接缩到 512x512 喂给模型细裂缝会消失。常见做法是滑窗推理把大图切成有重叠的小块逐块预测再把结果拼回去。重叠区域取平均或者取最大值避免拼接缝。窗口大小设 512步长设 256重叠 50%。这个参数下一条跨窗口的裂缝在两个窗口里都能被看到拼接后不会断。步长太大拼接缝明显步长太小推理时间翻倍。实测 1080P 图像切完大概 12 到 16 个窗口单帧推理在入门 GPU 上 200ms 左右勉强能到 5fps做辅助驾驶提示够用做实时控制不够。4. 交通路况识别车辆、行人与拥堵判断4.1 检测模型选型YOLO 还是 Faster R-CNN交通目标检测这个领域YOLO 系列和 Faster R-CNN 是两条主流路线。YOLO 是单阶段速度快适合实时Faster R-CNN 是两阶段精度高但慢。辅助驾驶场景对延迟敏感我一般选 YOLO 系列具体版本看算力。如果只有 CPU用 YOLOv5n 或者 YOLOv8n量化后能跑到 10fps 以上有 GPU 的话 YOLOv8s 或 YOLOv8m 精度更好。选型时别只看 mAP要看具体类别的召回率。行人、自行车这些弱势道路使用者漏检一个可能就是事故召回率比精度重要。训练时可以对行人类别加大损失权重或者在数据增强时对行人做更多的复制粘贴增强。4.2 拥堵判断从检测框到路况等级检测出车辆只是第一步还要判断拥堵。简单做法是统计画面里车辆的数量和占据面积比例。车辆数超过阈值、或者车辆框的总面积占画面比例超过 30%就判为拥堵。但这个规则太粗糙堵车时车距近但数量不一定多畅通时车多但速度快。更靠谱的做法是结合光流或者跟踪。对检测到的车辆做多目标跟踪算每辆车的位移速度速度低于阈值且持续若干帧判为拥堵。跟踪用 ByteTrack 或者 DeepSORTByteTrack 不需要外观特征速度快适合实时场景。速度阈值设多少城市道路 10km/h 以下持续 5 秒以上算拥堵这个值可以根据实际路段调整。# 基于检测框面积和数量的简单拥堵判断 def judge_congestion(detections, frame_area, veh_count_thresh15, area_ratio_thresh0.3): detections: list of [x1, y1, x2, y2, conf, cls] frame_area: 画面总面积 veh_boxes [d for d in detections if d[5] 0] # 假设 0 是车辆类别 count len(veh_boxes) total_area sum((d[2] - d[0]) * (d[3] - d[1]) for d in veh_boxes) area_ratio total_area / frame_area if count veh_count_thresh or area_ratio area_ratio_thresh: return 拥堵 elif count veh_count_thresh * 0.5: return 缓行 else: return 畅通这个函数是规则版的起点veh_count_thresh和area_ratio_thresh要根据摄像头安装高度和视角标定。摄像头装得高、视角广同样拥堵程度下画面里车更多阈值要调大。实际项目里我会先用一批标注好的拥堵/畅通视频片段跑一遍看两个指标的分布再定阈值。4.3 把两路结果合成驾驶提示路面分析和交通路况识别的输出要合成一个提示信号。逻辑是这样的如果路面检测到严重病害坑洼面积超过阈值且当前车速对应的制动距离内无法避开提示「前方路面异常」如果交通检测到前方有行人且距离小于安全距离提示「注意行人」如果拥堵判断为拥堵提示「前方拥堵」。多个提示同时触发时按危险程度排序行人优先级最高路面病害次之拥堵最低。这个合成逻辑用简单的规则引擎就行不需要上复杂的决策模型。规则清晰、可解释、好调试出问题能快速定位是哪一路误报。等规则跑稳了再考虑用学习的方法做融合。5. 避坑与排查那些让项目卡住的真实问题5.1 模型在验证集上指标很好一上车就废现象训练时 mAP 0.85分割 IoU 0.7拿测试视频一跑漏检严重路面病害基本检不出。原因训练集和实际场景的域差异。公开数据集多是晴天、白天、干燥路面实际行车会遇到逆光、雨天、夜间、路面反光。模型没见过这些泛化直接崩。解决训练时加激进的数据增强随机亮度对比度调整、加雨雾噪声、模拟运动模糊。更彻底的做法是采一批实际场景的数据微调哪怕只有几百张也能把指标拉回来一大截。别指望公开数据集训完就能直接用。5.2 推理速度跟不上画面卡成幻灯片现象单帧推理超过 500ms视频播放一顿一顿根本没法做实时提示。原因输入分辨率太高、模型太大、或者没做推理优化。1080P 直接喂给模型计算量是 512x512 的四倍多。解决先降输入分辨率到 640x640 或 512x512精度损失通常可接受。然后做模型量化PyTorch 的torch.quantization或者 ONNX Runtime 的量化INT8 量化后速度能翻倍。再不行就换更小的骨干MobileNetV3 换 MobileNetV2 的窄版或者用 YOLOv8n 替代 YOLOv8s。推理框架从 PyTorch 原生换成 ONNX Runtime 或 TensorRT也有明显提升。5.3 分割掩码边缘抖动视频里一闪一闪现象单帧看分割结果还行连续播放时病害区域边缘不停闪烁面积忽大忽小。原因逐帧独立推理没有时序一致性约束。相邻帧的预测结果有微小差异累积起来就是闪烁。解决加时序平滑。简单做法是对连续几帧的分割概率图做滑动平均再取阈值。或者用光流把前一帧的结果 warp 到当前帧和当前帧预测做融合。如果项目允许用视频分割模型比如 STM 或者 DEVA它们本身有时序建模但计算量更大。课程项目用滑动平均就够了窗口设 5 帧延迟增加 100ms 左右可接受。5.4 拥堵判断在傍晚和夜间完全失效现象白天拥堵判断挺准一到傍晚或者夜间车辆检测框数量骤降拥堵全判成畅通。原因低照度下图像对比度低车辆特征不明显检测模型召回率下降。加上车灯眩光画面局部过曝车辆轮廓被淹没。解决训练时加入低照度增强比如 Gamma 校正、直方图均衡化的随机版本。推理前先做一次低光增强用 Zero-DCE 这类轻量增强网络或者简单的 CLAHE。另外夜间拥堵判断可以降低车辆数量阈值因为夜间画面里可见车辆本来就少阈值不调会一直判畅通。5.5 标注数据里混入了错误标签训练 loss 震荡现象训练 loss 下降到一定程度后开始剧烈震荡验证指标忽好忽坏。原因标注数据里有错误标签比如把背景标成病害、把车辆框标到行人身上。这些噪声样本在训练后期梯度贡献大把模型带偏。解决训练前做一轮数据清洗。用模型预训练一轮找出 loss 特别高的样本人工复查。或者用交叉验证多个模型都预测错的样本大概率是标注问题。清洗一遍再训练loss 曲线会平滑很多。这个步骤不能省标注质量决定模型上限。6. 进阶技巧用知识蒸馏把大模型压进车机前面讲的方案跑在笔记本或者开发板上真要往车机里塞算力和功耗都是硬约束。这时候知识蒸馏是个实用手段。思路是先用一个大模型比如 ResNet50 骨干 完整分割检测头在训练集上训到高精度把它当教师模型然后用它来指导一个小模型MobileNetV3 骨干训练。小模型不仅学真值标签还学教师模型的软输出软输出里包含了类间相似性信息比硬标签信息量大。具体做法损失函数里加一项蒸馏损失让小模型的输出分布逼近教师模型的输出分布。分割任务用 KL 散度衡量两个概率图的差异检测任务对分类分支做蒸馏回归分支因为尺度敏感一般不蒸馏。温度参数 T 设 3 到 5T 越大软标签越平滑信息越丰富但太小了蒸馏效果不明显太大了学生学不到细节。# 知识蒸馏损失学生分割输出逼近教师 def distillation_loss(student_logits, teacher_logits, T4.0): # 教师和学生都做 softmax教师用高温 student_soft torch.log_softmax(student_logits / T, dim1) teacher_soft torch.softmax(teacher_logits / T, dim1) # KL 散度乘 T^2 保持梯度尺度 return nn.functional.kl_div(student_soft, teacher_soft, reductionbatchmean) * (T * T)蒸馏后的小模型精度通常能到教师模型的 95% 以上参数量只有十分之一推理速度翻几倍。我实测过一个路面分割任务教师模型 IoU 0.72蒸馏后小模型 IoU 0.69参数量从 25M 降到 2.5M推理从 180ms 降到 35ms。这个 trade-off 在辅助驾驶场景完全值得。验证蒸馏效果时别只看最终指标要看学生模型在困难样本上的表现。教师模型能检出的细裂缝学生如果检不出说明蒸馏时温度或者损失权重没调好。我一般会固定教师模型扫一遍 T 和蒸馏损失权重的组合选验证集上最好的那组。这个调参过程比较费时间但比重新设计网络结构划算。最后说个习惯每次改完模型或者数据一定用同一段测试视频跑一遍肉眼过一遍结果。指标是黑匣子画面不会骗人。我吃过太多次指标涨了但实际效果变差的亏后来养成了指标和可视化双确认的习惯。希望帮到你。本文还有配套的精品资源点击获取 基于计算机视觉的车辆辅助驾驶系统：路面分析与交通路况识别实战
简介这是一套面向计算机视觉与智能交通方向的车辆辅助驾驶系统项目资料适合人工智能、通信工程、自动化、电子信息等专业的在校学生、教师及企业技术人员用于毕业设计、课程设计或项目立项演示。资源围绕路面分析、交通路况识别与辅助驾驶展开包含完整源码与详细文档代码经过测试可正常运行并已通过导师评审与答辩获得95分评价。压缩包共110个文件约9.88MB以48个C头文件、24个cpp源文件为核心实现辅以txt说明、xml配置、md文档及少量图片与脚本涵盖JSON解析、HTTP通信、模型配置等模块目录结构清晰便于按功能检索与二次开发。目前已有46人学习关注。读者可据此掌握从图像处理到路况识别的完整实现思路理解工程化代码组织方式并在此基础上修改扩展功能快速完成毕设、课设或作业任务。1. 路面分析 交通路况识别一套车辆辅助驾驶系统到底在做什么很多人第一次听到「车辆辅助驾驶系统」这个词脑子里浮现的是激光雷达、高精地图、域控制器这些贵得离谱的东西。但如果你把预算压到几百块、算力压到一块入门级 GPU 甚至 CPU还想让车「看懂路」那能依靠的就只剩计算机视觉这一条路。这套方案要解决的核心问题很具体用摄像头拍到的画面判断前方路面有没有坑洼裂缝、车道线还在不在、前面有没有车和行人、当前路况是畅通还是拥堵最后把这些结论汇总成一个能提示驾驶员的信号。它适合谁适合做计算机视觉大作业的学生、想入门辅助驾驶的嵌入式工程师、以及手里只有普通摄像头和一台笔记本、想先把整条链路跑通再谈优化的开发者。路面分析和交通路况识别这两件事一个管「路好不好」一个管「周围什么情况」合起来才是辅助驾驶该有的感知底座。2. 从一帧图像到驾驶提示整条视觉链路的拆解2.1 为什么不能一个模型包打天下刚上手的人最容易犯的错是想着训练一个「万能模型」输入一张图直接输出「前方有坑、左边有车、路况拥堵」。这个思路在 demo 阶段看着很美一上真实数据就翻车。原因在于路面分析和交通路况识别对图像特征的需求根本不一样。路面病害检测看的是纹理和灰度突变坑洼边缘、裂缝走向这些细节在浅层特征里最明显网络不需要太深而车辆、行人、交通标志的识别依赖语义级别的形状和上下文需要更深的骨干网络和更大的感受野。把两者塞进一个头梯度会互相打架最后两边都不精。常见做法是拆成两条并行的分支共享一个轻量骨干做特征提取然后各自接检测头。骨干可以用 MobileNetV3 或者 ShuffleNetV2参数量小、推理快适合辅助驾驶这种对延迟敏感的场景。路面分支接一个分割头输出像素级的病害区域掩码交通目标分支接一个检测头输出车辆、行人、交通灯的边界框和类别。两条分支在训练时可以分别设不同的学习率路面分支收敛快学习率调小一点防止过拟合。这里有个选型上的取舍要讲清楚如果你只是做课程项目或者验证可行性完全可以用两个独立模型分别跑省去共享骨干的联调麻烦。共享骨干的价值在于省算力但代价是训练时两条分支的 batch 组织、损失权重都要仔细调新手很容易在这里卡住。我一般建议先用两个独立模型把效果跑出来确认数据管线和评估指标没问题再考虑合并。2.2 数据从哪来怎么标这套系统最耗时间的不是写模型是搞数据。路面病害的公开数据集不多常见的有 CrackForest、RDD2022 这类主要覆盖裂缝坑洼的样本偏少。交通目标检测可以用 BDD100K、KITTI 或者国内的一些路测数据集。但真实项目里公开数据集只能当预训练用最终还是要自己采。采集设备就是普通行车记录仪或者手机固定在挡风玻璃后分辨率 1080P 足够帧率 30fps 采视频后期抽帧。抽帧策略要注意连续帧之间差异很小全抽会导致大量冗余样本模型见过多相似图会过拟合。我一般按每秒抽 2 到 3 帧遇到弯道、颠簸路段加密抽。标注工具用 LabelImg 标检测框用 LabelMe 标分割掩码导出格式统一成 COCO 或者 YOLO 格式。标注规范必须提前定死否则后面返工能让人崩溃。路面病害的边界怎么算裂缝的起止点在哪坑洼的轮廓要不要包含边缘的碎裂区这些都要写进标注手册让所有标注人员对齐。交通目标那边遮挡超过 50% 的车辆标不标、远处小于 20 像素的行人标不标也要有明确规则。血泪经验是标注规范没定好就开工标到一半发现标准不一致几千张图全部重标。2.3 最小可跑通的训练脚本下面这段代码是一个双分支模型的训练骨架用 PyTorch 写骨干共享两个头分别输出分割和检测结果。这不是完整工程但能让你看清数据怎么流、损失怎么组。import torch import torch.nn as nn import torchvision.models as models class SharedBackbone(nn.Module): def __init__(self): super().__init__() # 用 MobileNetV3 做骨干取前几层特征 mobilenet models.mobilenet_v3_small(pretrainedTrue) self.features mobilenet.features # 输出通道 576 self.out_channels 576 def forward(self, x): return self.features(x) class RoadSegHead(nn.Module): def __init__(self, in_ch, num_classes2): super().__init__() # 简单上采样分割头num_classes2 表示背景和病害 self.conv nn.Sequential( nn.Conv2d(in_ch, 256, 3, padding1), nn.BatchNorm2d(256), nn.ReLU(inplaceTrue), nn.Conv2d(256, num_classes, 1) ) def forward(self, x): x self.conv(x) # 双线性上采样回输入尺寸 return nn.functional.interpolate(x, scale_factor32, modebilinear, align_cornersFalse) class TrafficDetHead(nn.Module): def __init__(self, in_ch, num_anchors3, num_classes4): super().__init__() # 检测头输出每个 anchor 的类别和框偏移 self.num_anchors num_anchors self.num_classes num_classes self.conv nn.Conv2d(in_ch, num_anchors * (num_classes 5), 1) def forward(self, x): return self.conv(x) class AuxDrivingNet(nn.Module): def __init__(self): super().__init__() self.backbone SharedBackbone() self.seg_head RoadSegHead(self.backbone.out_channels) self.det_head TrafficDetHead(self.backbone.out_channels) def forward(self, x): feat self.backbone(x) seg_out self.seg_head(feat) det_out self.det_head(feat) return seg_out, det_out # 损失组合分割用交叉熵检测用简化版多任务损失 def compute_loss(seg_pred, seg_gt, det_pred, det_gt): seg_loss nn.functional.cross_entropy(seg_pred, seg_gt) # det_gt 这里假设已经编码成偏移和类别实际项目要接完整检测损失 det_loss nn.functional.mse_loss(det_pred, det_gt) return seg_loss 0.5 * det_loss # 权重 0.5 是经验值可调这段代码的关键点有三个。第一骨干用的是mobilenet_v3_small的features部分输出通道 576特征图尺寸是输入的 1/32所以分割头里用scale_factor32上采样回去。第二分割头输出 2 类背景和病害实际项目里病害可以再细分裂缝、坑洼、修补改num_classes就行。第三检测头这里简化成了直接回归真实项目要换成 anchor-based 或者 anchor-free 的完整检测损失比如 FCOS 或者 YOLO 的损失函数。损失权重 0.5 是我在几个数据集上试出来的起点分割损失通常比检测损失大一个量级不加权检测分支会被淹没。参数上要调的学习率初始设 1e-3用余弦退火batch size 根据显存来1080P 输入下 8 到 16 比较稳训练轮数看数据量一万张图大概 50 到 80 轮收敛。如果分割结果边缘毛糙把分割头的卷积核从 3 换成 5感受野大一点会好。3. 路面病害检测从裂缝到坑洼的像素级判断3.1 分割比检测更适合路面分析的原因路面病害有个特点形状不规则、边界模糊、大小差异极大。一条细裂缝可能只占几个像素宽一个坑洼可能横跨半个车道。用目标检测框去框这些东西框里大量是背景像素回归出来的框要么太松要么太紧评估指标 IoU 很难看。分割是逐像素分类裂缝的细长结构、坑洼的不规则轮廓都能保留后续算病害面积、严重程度也直接基于像素统计更合理。但分割的代价是标注成本高。检测框画个矩形就行分割要沿边界描点。折中方案是先用检测框粗标再在框内做弱监督分割或者用 SAM 这类分割大模型辅助生成掩码再人工修。我一般建议课程项目直接用分割标注量控制在两千张以内配合数据增强也能出效果。3.2 类别不平衡怎么处理路面图像里病害像素占比通常不到 5%背景占 95% 以上。直接训练模型会倾向于全预测背景准确率看着 95% 很高实际一个病害都没检出来。这是分割任务里最经典的坑。处理办法有几个。一是损失函数用 Dice Loss 或者 Focal LossDice 直接优化预测和真值的重叠度对类别不平衡不敏感Focal Loss 降低易分类样本的权重让模型关注难样本。二是采样时保证每个 batch 里至少有几张含病害的图别让整个 batch 全是好路。三是后处理时对病害类别的概率图做阈值调整背景阈值设 0.5病害阈值可以降到 0.3宁可误检不可漏检辅助驾驶场景漏检代价更大。# Dice Loss 实现用于路面分割 class DiceLoss(nn.Module): def __init__(self, smooth1.0): super().__init__() self.smooth smooth def forward(self, pred, target): # pred: [B, C, H, W] logits, target: [B, H, W] 类别索引 pred torch.softmax(pred, dim1) # 只取病害类别假设索引为 1 pred_disease pred[:, 1, :, :] target_disease (target 1).float() intersection (pred_disease * target_disease).sum() union pred_disease.sum() target_disease.sum() dice (2. * intersection self.smooth) / (union self.smooth) return 1 - dice这个 Dice Loss 只对病害类别算背景不参与直接绕开不平衡问题。smooth是防止分母为零的平滑项设 1.0 就行。实际训练时我会把 Dice Loss 和交叉熵按 1:1 加权组合交叉熵提供稳定的梯度Dice 负责拉高重叠度。3.3 推理阶段的滑窗与拼接路面图像分辨率高直接缩到 512x512 喂给模型细裂缝会消失。常见做法是滑窗推理把大图切成有重叠的小块逐块预测再把结果拼回去。重叠区域取平均或者取最大值避免拼接缝。窗口大小设 512步长设 256重叠 50%。这个参数下一条跨窗口的裂缝在两个窗口里都能被看到拼接后不会断。步长太大拼接缝明显步长太小推理时间翻倍。实测 1080P 图像切完大概 12 到 16 个窗口单帧推理在入门 GPU 上 200ms 左右勉强能到 5fps做辅助驾驶提示够用做实时控制不够。4. 交通路况识别车辆、行人与拥堵判断4.1 检测模型选型YOLO 还是 Faster R-CNN交通目标检测这个领域YOLO 系列和 Faster R-CNN 是两条主流路线。YOLO 是单阶段速度快适合实时Faster R-CNN 是两阶段精度高但慢。辅助驾驶场景对延迟敏感我一般选 YOLO 系列具体版本看算力。如果只有 CPU用 YOLOv5n 或者 YOLOv8n量化后能跑到 10fps 以上有 GPU 的话 YOLOv8s 或 YOLOv8m 精度更好。选型时别只看 mAP要看具体类别的召回率。行人、自行车这些弱势道路使用者漏检一个可能就是事故召回率比精度重要。训练时可以对行人类别加大损失权重或者在数据增强时对行人做更多的复制粘贴增强。4.2 拥堵判断从检测框到路况等级检测出车辆只是第一步还要判断拥堵。简单做法是统计画面里车辆的数量和占据面积比例。车辆数超过阈值、或者车辆框的总面积占画面比例超过 30%就判为拥堵。但这个规则太粗糙堵车时车距近但数量不一定多畅通时车多但速度快。更靠谱的做法是结合光流或者跟踪。对检测到的车辆做多目标跟踪算每辆车的位移速度速度低于阈值且持续若干帧判为拥堵。跟踪用 ByteTrack 或者 DeepSORTByteTrack 不需要外观特征速度快适合实时场景。速度阈值设多少城市道路 10km/h 以下持续 5 秒以上算拥堵这个值可以根据实际路段调整。# 基于检测框面积和数量的简单拥堵判断 def judge_congestion(detections, frame_area, veh_count_thresh15, area_ratio_thresh0.3): detections: list of [x1, y1, x2, y2, conf, cls] frame_area: 画面总面积 veh_boxes [d for d in detections if d[5] 0] # 假设 0 是车辆类别 count len(veh_boxes) total_area sum((d[2] - d[0]) * (d[3] - d[1]) for d in veh_boxes) area_ratio total_area / frame_area if count veh_count_thresh or area_ratio area_ratio_thresh: return 拥堵 elif count veh_count_thresh * 0.5: return 缓行 else: return 畅通这个函数是规则版的起点veh_count_thresh和area_ratio_thresh要根据摄像头安装高度和视角标定。摄像头装得高、视角广同样拥堵程度下画面里车更多阈值要调大。实际项目里我会先用一批标注好的拥堵/畅通视频片段跑一遍看两个指标的分布再定阈值。4.3 把两路结果合成驾驶提示路面分析和交通路况识别的输出要合成一个提示信号。逻辑是这样的如果路面检测到严重病害坑洼面积超过阈值且当前车速对应的制动距离内无法避开提示「前方路面异常」如果交通检测到前方有行人且距离小于安全距离提示「注意行人」如果拥堵判断为拥堵提示「前方拥堵」。多个提示同时触发时按危险程度排序行人优先级最高路面病害次之拥堵最低。这个合成逻辑用简单的规则引擎就行不需要上复杂的决策模型。规则清晰、可解释、好调试出问题能快速定位是哪一路误报。等规则跑稳了再考虑用学习的方法做融合。5. 避坑与排查那些让项目卡住的真实问题5.1 模型在验证集上指标很好一上车就废现象训练时 mAP 0.85分割 IoU 0.7拿测试视频一跑漏检严重路面病害基本检不出。原因训练集和实际场景的域差异。公开数据集多是晴天、白天、干燥路面实际行车会遇到逆光、雨天、夜间、路面反光。模型没见过这些泛化直接崩。解决训练时加激进的数据增强随机亮度对比度调整、加雨雾噪声、模拟运动模糊。更彻底的做法是采一批实际场景的数据微调哪怕只有几百张也能把指标拉回来一大截。别指望公开数据集训完就能直接用。5.2 推理速度跟不上画面卡成幻灯片现象单帧推理超过 500ms视频播放一顿一顿根本没法做实时提示。原因输入分辨率太高、模型太大、或者没做推理优化。1080P 直接喂给模型计算量是 512x512 的四倍多。解决先降输入分辨率到 640x640 或 512x512精度损失通常可接受。然后做模型量化PyTorch 的torch.quantization或者 ONNX Runtime 的量化INT8 量化后速度能翻倍。再不行就换更小的骨干MobileNetV3 换 MobileNetV2 的窄版或者用 YOLOv8n 替代 YOLOv8s。推理框架从 PyTorch 原生换成 ONNX Runtime 或 TensorRT也有明显提升。5.3 分割掩码边缘抖动视频里一闪一闪现象单帧看分割结果还行连续播放时病害区域边缘不停闪烁面积忽大忽小。原因逐帧独立推理没有时序一致性约束。相邻帧的预测结果有微小差异累积起来就是闪烁。解决加时序平滑。简单做法是对连续几帧的分割概率图做滑动平均再取阈值。或者用光流把前一帧的结果 warp 到当前帧和当前帧预测做融合。如果项目允许用视频分割模型比如 STM 或者 DEVA它们本身有时序建模但计算量更大。课程项目用滑动平均就够了窗口设 5 帧延迟增加 100ms 左右可接受。5.4 拥堵判断在傍晚和夜间完全失效现象白天拥堵判断挺准一到傍晚或者夜间车辆检测框数量骤降拥堵全判成畅通。原因低照度下图像对比度低车辆特征不明显检测模型召回率下降。加上车灯眩光画面局部过曝车辆轮廓被淹没。解决训练时加入低照度增强比如 Gamma 校正、直方图均衡化的随机版本。推理前先做一次低光增强用 Zero-DCE 这类轻量增强网络或者简单的 CLAHE。另外夜间拥堵判断可以降低车辆数量阈值因为夜间画面里可见车辆本来就少阈值不调会一直判畅通。5.5 标注数据里混入了错误标签训练 loss 震荡现象训练 loss 下降到一定程度后开始剧烈震荡验证指标忽好忽坏。原因标注数据里有错误标签比如把背景标成病害、把车辆框标到行人身上。这些噪声样本在训练后期梯度贡献大把模型带偏。解决训练前做一轮数据清洗。用模型预训练一轮找出 loss 特别高的样本人工复查。或者用交叉验证多个模型都预测错的样本大概率是标注问题。清洗一遍再训练loss 曲线会平滑很多。这个步骤不能省标注质量决定模型上限。6. 进阶技巧用知识蒸馏把大模型压进车机前面讲的方案跑在笔记本或者开发板上真要往车机里塞算力和功耗都是硬约束。这时候知识蒸馏是个实用手段。思路是先用一个大模型比如 ResNet50 骨干 完整分割检测头在训练集上训到高精度把它当教师模型然后用它来指导一个小模型MobileNetV3 骨干训练。小模型不仅学真值标签还学教师模型的软输出软输出里包含了类间相似性信息比硬标签信息量大。具体做法损失函数里加一项蒸馏损失让小模型的输出分布逼近教师模型的输出分布。分割任务用 KL 散度衡量两个概率图的差异检测任务对分类分支做蒸馏回归分支因为尺度敏感一般不蒸馏。温度参数 T 设 3 到 5T 越大软标签越平滑信息越丰富但太小了蒸馏效果不明显太大了学生学不到细节。# 知识蒸馏损失学生分割输出逼近教师 def distillation_loss(student_logits, teacher_logits, T4.0): # 教师和学生都做 softmax教师用高温 student_soft torch.log_softmax(student_logits / T, dim1) teacher_soft torch.softmax(teacher_logits / T, dim1) # KL 散度乘 T^2 保持梯度尺度 return nn.functional.kl_div(student_soft, teacher_soft, reductionbatchmean) * (T * T)蒸馏后的小模型精度通常能到教师模型的 95% 以上参数量只有十分之一推理速度翻几倍。我实测过一个路面分割任务教师模型 IoU 0.72蒸馏后小模型 IoU 0.69参数量从 25M 降到 2.5M推理从 180ms 降到 35ms。这个 trade-off 在辅助驾驶场景完全值得。验证蒸馏效果时别只看最终指标要看学生模型在困难样本上的表现。教师模型能检出的细裂缝学生如果检不出说明蒸馏时温度或者损失权重没调好。我一般会固定教师模型扫一遍 T 和蒸馏损失权重的组合选验证集上最好的那组。这个调参过程比较费时间但比重新设计网络结构划算。最后说个习惯每次改完模型或者数据一定用同一段测试视频跑一遍肉眼过一遍结果。指标是黑匣子画面不会骗人。我吃过太多次指标涨了但实际效果变差的亏后来养成了指标和可视化双确认的习惯。希望帮到你。本文还有配套的精品资源点击获取