简介本资源是一套面向智能小车与自动驾驶初学者、高校课程设计及科研入门者的车道线检测实战项目基于深度学习语义分割技术解决道路图像中车道线精准识别与像素级定位问题。压缩包共1554个文件含1543张标注PNG图像训练/验证用、3个核心Python脚本数据加载、模型训练与推理、1个Jupyter Notebook主程序含完整流程演示、1个模型权重.pth文件、1个README.md说明文档及5个编译字节码文件整体大小835.89MB结构清晰、模块解耦便于理解语义分割落地全流程。目前已有54人学习下载资源提供从数据预处理、UNetLane定制网络构建、端到端训练到实时检测部署的全链路实现配套文档详述环境配置、关键参数设置与常见报错解决方案显著降低复现门槛是快速掌握车道线检测工程实践的高价值开源素材。 熟悉智能小车开发的朋友应该都清楚车道线检测这个需求看起来不难但真正做起来特别容易翻车。传统CV方案换个光照就失效简单模型扛不住弯道和阴影干扰这也是为什么现在主流方案都转向了深度学习。这个项目走的是语义分割路线把每个像素分类成“车道线”和“背景”本质上是图像分割任务配合Python生态里的开源框架能在小车这种算力有限的平台上跑出稳定的检测效果。我花了一周时间把这个项目完整过了一遍从数据集整理、模型训练到部署小车实跑坑踩了不少但跑通之后的效果确实让人放心。这篇文章就把整套实现思路、关键决策和踩坑记录逐项拆开讲清楚不管是做课程设计、竞赛项目还是单纯想入门自动驾驶视觉方向都有可以直接照抄的价值。1. 项目整体设计与方案选型1.1 为什么选择语义分割而不是传统视觉方案很多刚开始接触车道线检测的人第一反应是用Hough变换配合边缘检测来找直线这个方案在结构化道路、光照均匀的环境下确实能用但实际跑起来问题非常多。比如路面有裂缝、树影斑驳、车辆遮挡Canny边缘检测会输出大量噪声点Hough变换就很难从中筛出真正的车道线。更致命的是传统方案在弯道场景几乎无解需要额外拟合曲线模型一遇到曲率变化大的路况就得重新调参数。语义分割天然适合这个场景核心原因有两个。第一它的输出是像素级分类结果模型在训练时见过的场景特征会内化为对“车道线”这个语义概念的理解而不是简单依赖边缘梯度信息去猜测因此对阴影、光照变化有天然的抗干扰能力。第二分割结果是逐像素掩码后端无论是拟合直线还是三次曲线都能直接拿像素坐标做输入不需要像传统方案那样先做特征工程再判断线型逻辑链更短误差累积更少。当然语义分割对算力的消耗比传统CV要高不少。这是选型时必须认知清楚的点你是在用算力换稳定性。但我们在小车平台上做了模型裁剪实际推理单帧耗时能控制在40毫秒以内实时性完全够用。1.2 网络结构选型U-Net为什么够用项目源码里用的是U-Net结构的变体没上DeepLabV3也没用PSPNet很多人问为什么。原因不复杂U-Net的编解码对称结构在语义分割任务里属于“性价比最高”的那种设计。编码器不断下采样提取高维语义特征解码器逐步上采样恢复空间分辨率中间用跳层连接把低级轮廓信息和高级语义特征融合在一起对车道线这种“细长连续且依赖上下文”的目标来说非常合适。DeepLabV3用了空洞卷积和ASPP模块理论感受野更大但在小车这种边缘设备上它带来的推理延迟增量会明显吃掉实时帧率性能收益却没那么明显。U-Net相对轻量配合MobileNet之类的轻量编码器在树莓派或者Jetson Nano上都能跑得动。源码里默认用的是自定义的四层下采样结构每层通道数分别是32、64、128、256参数量不大但车道线这种目标不太需要超大感受野这个规模已经够用。还有人会纠结用ENet还是U-NetENet确实更轻但它为了极限压缩牺牲了不少精度在弯道和小曲率路段表现一般。拿这个项目来说U-Net基本属于“闭眼选不会错”的方案。1.3 数据集与标注策略项目里的数据集分为两部分一部分是开源街景数据一部分是自采的路面数据。开源数据直接下载标注好的车道线掩码即可多数是TuSimple格式。但TuSimple主要覆盖高速公路场景弯道比例不高所以项目另外补充了从园区路面采集的视频帧手工标注后加入训练集。这里有个容易被忽略的问题标注的一致性。车道线的类别定义必须统一。项目里将车道线分为单类二值掩码没有区分实线虚线。因为后续后处理只需要提取中心线坐标不需要区分线型类别拆太细反而增加了训练难度和推理复杂度。如果你后续想扩展区分虚实线需要在标注时就分两个类别同时修改模型输出通道数和损失函数权重这个扩展方向项目说明里也有提到。标注工具用的LabelMe导出JSON格式后写脚本转成PNG灰度掩码图。掩码图中车道线像素值为255背景为0。训练时读入后除以255归一化到[0,1]这样二分类交叉熵损失才能正确计算。数据总量约8000张其中6000张训练2000张验证没有额外划分测试集因为部署阶段会直接用小车上采集的真实路面视频做最终验证。2. 环境搭建与数据准备2.1 Python环境与依赖版本这个项目的环境配置不算复杂但版本匹配容易出问题。实测可用的组合是Python 3.8 PyTorch 1.10.2 CUDA 11.3。PyTorch版本别随便上2.x因为项目里的部分API在2.0里做了调整旧代码需要改import路径新手很容易卡在这一步。核心依赖如下torch1.10.2 torchvision0.11.3 opencv-python4.5.5.64 numpy1.21.6 pillow9.2.0 matplotlib3.5.3 tqdm4.64.1训练时用GPU2080Ti或3060都能跑显存8GB就够。batch size设为8输入分辨率256x512大约40分钟跑完一个epoch整个训练约50个epoch两小时左右能收敛。如果手里没有GPU也能用CPU训练但一个epoch可能要10分钟以上建议直接把源码里的预训练权重拿来微调不要从头训。有个细节值得说OpenCV版本很关键。4.5.x的findContours返回值是2个到4.x后期改成2个了但早期版本会返回3个值导致解包报错。如果装了其他版本代码里的后处理部分需要按版本调整。2.2 数据集格式与预处理流程数据集目录结构如下dataset/ ├── train/ │ ├── images/ # 原始图像jpg格式 │ └── masks/ # 标注掩码png格式 ├── val/ │ ├── images/ │ └── masks/ └── test/ └── images/ # 推理时使用的未标注图像预处理流程最重要的是图像尺寸统一。源码里默认将输入resize到256x512宽x高。为什么不选正方形因为车道线的有效信息集中在图像中下方且路面在水平方向更宽256x512的矩形比例能保留更多横向空间信息让模型更好地理解车道走向。归一化参数使用了ImageNet的均值方差mean[0.485, 0.456, 0.406]std[0.229, 0.224, 0.225]。虽然这个参数是为ImageNet分类任务统计出来的但迁移到车道线分割任务同样适用因为预训练模型已经在这个分布下收敛过继续沿用能加速微调过程。Mask处理时有一个容易踩的坑直接读取灰度图时OpenCV的imread默认会以三通道读取掩码图需要强制加cv2.IMREAD_GRAYSCALE参数否则后续计算损失时形状不匹配。项目里专门封装了SegDataset类__getitem__里返回图像张量、掩码张量和文件路径后者在可视化调试时很实用能直接定位是哪张图出了问题。2.3 数据增强策略与细节这个项目里的数据增强引入了随机水平翻转、随机亮度对比度调整和随机裁剪缩放。随机水平翻转需要注意车道线位置在翻转后语义不变但如果是虚实线都标注的数据集翻转后虚实线的位置就反了需要同步翻转掩码。项目里当前只做二值分割所以翻转安全。随机亮度对比度调整这个增强对外场光线变化特别有效。小车上午跑和傍晚跑路面亮度差异很大如果不做亮度增强模型在低光环境下漏检率会明显上升。源码里通过cv2.addWeighted实现import cv2 import numpy as np def adjust_brightness_contrast(image, alpha1.2, beta15): return cv2.convertScaleAbs(image, alphaalpha, betabeta)实际使用中alpha范围设置在[0.8, 1.4]beta范围在[-20, 20]。范围太小没作用太大会让掩码目标变得模糊不清影响训练稳定性。随机裁剪缩放则通过RandomResizedCrop实现但需要保证裁剪比例不能过低否则会丢失车道线上下文。项目里scale范围设置为[0.5, 1.0]ratio限制在[1.0, 1.0]保持不变相当于只做缩放不改变宽高比。3. 模型训练核心细节解析3.1 损失函数选择交叉熵与Dice Loss的取舍语义分割最基础的损失是逐像素交叉熵。二分类场景下每个像素的预测概率和真实标签做Binary Cross-Entropy Loss然后求平均。这个损失函数本身没有太大问题但车道线有一个特殊性正负样本极度不均衡。一张256x512的图上车道线像素通常只占2%~5%背景占了绝大多数。如果直接用BCE模型会倾向于把所有像素都预测为背景因为这样损失值已经很小了。项目源码里采用了BCE Loss和Dice Loss加权组合的方式这是处理分割任务中类别不平衡问题的经典手段。Dice Loss直接从重叠度角度优化对前景区域非常敏感即使正样本很少也能给出有意义的梯度信号。公式如下import torch import torch.nn.functional as F def dice_loss(pred, target, smooth1.0): pred torch.sigmoid(pred) pred_flat pred.view(-1) target_flat target.view(-1) intersection (pred_flat * target_flat).sum() return 1 - (2.0 * intersection smooth) / (pred_flat.sum() target_flat.sum() smooth)最终损失是loss bce_loss dice_loss两者的权重是1:1。实测下来比单独使用BCE或者单独使用Dice Loss均更好。单独使用Dice Loss在训练初期会有梯度不稳定问题预测概率接近0时Dice值波动非常大而加上BCE作为“锚”能让训练过程稳定不少。3.2 训练超参数配置与优化器选择项目源码里默认的优化器是Adam学习率3e-4weight decay 1e-4。这里有一个非常关键的经验weight decay不能设太大否则U-Net解码器部分的参数会被过度正则化导致输出掩码边缘出现“锯齿感”。我之前试着把weight decay调到1e-2结果分割出的车道线边缘毛糙得没法用。学习率调度器用的是CosineAnnealingLRT_max设为50最小学习率1e-6。相比StepLR按固定步数衰减余弦退火能在训练后期保持较低学习率的同时仍然保留一些探索能力对分割任务这种高维非凸优化更友好。batch size在显存允许的情况下越大越好但也不要盲目调大。实测batch size从4调到8mIoU涨了约1.2个百分点从8调到16只涨了0.3个百分点而显存占用却翻了一倍。对边缘设备部署场景没必要追求极限精度8这个档位性价比最高。训练epoch数建议不要低于50。U-Net在30个epoch左右会开始产生明显效果但车道线这种细长目标需要更长的时间去收敛边缘细节过早停止会导致分割掩码出现断裂。源码里在训练过程中每个epoch结束都会在验证集上计算mIoU并自动保存最优权重这一步很有用防止后期过拟合时覆盖掉好的权重。3.3 评估指标与效果验证语义分割的评估指标主要看mIoU和像素准确率。项目里mIoU指标分成背景类和车道线类分别计算然后取平均。这个项目背景类mIoU通常在99%左右参考价值不大真正要盯的是车道线类别的IoU。训练好的模型在验证集上车道线IoU在83%~87%之间根据数据分布不同会有波动。评估模型时不要只看IoU还要关注预测掩码的连通性。一个很常见的现象是模型在直线路段表现很好但到了弯道路段掩码会从中段断开被截成两截或者多截。IoU指标看整体重叠度可能依然偏高但实际部署时车道线断掉了后续拟合就无法得到完整的车道曲线。所以我在验证时额外跑了一个“最大连通域面积占比”的辅助指标统计预测掩码面积最大的连通区域占全部预测前景像素的比例。这个比例低于80%就说明掩码断裂严重需要针对性调整。优化方法通常是增加数据集中弯道样本的比例或者提高输入分辨率让模型能保留更多细节这个经验在项目说明里也补充了。4. 智能小车部署与车道线后处理4.1 模型轻量化与格式转换训练好的PyTorch模型不能直接放到小车上的嵌入式环境里跑原因有两层一是依赖库体积太大树莓派这类设备上装完整版PyTorch占用空间和内存都超出预算二是推理速度不够PyTorch的CPU推理效率远不如专门优化过的推理引擎。项目里的部署方案分两条线。如果小车用的是树莓派4B或者类似Linux环境模型通过ONNX导出后用ONNX Runtime进行CPU推理。实测树莓派4B上推理一张256x512的图像大约需要80毫秒加上后处理和串口通信整条链路稳定在15~20FPS。如果小车用的是Jetson Nano模型直接转成TensorRT的engine文件FP16精度下推理一张图只需要20毫秒能跑到30FPS以上。ONNX导出代码示例如下import torch model torch.load(best_model.pth, map_locationcpu) model.eval() dummy_input torch.randn(1, 3, 256, 512) torch.onnx.export( model, dummy_input, lane.onnx, input_names[input], output_names[output], opset_version11 )导出后务必用onnxruntime做一次推理对比输出确认数值误差在可接受范围内。PyTorch转ONNX最常见的坑是某些自定义算子不支持导出但这个项目用的都是标准卷积、BN、ReLU没有这个问题。4.2 车道线后处理从掩码到坐标模型输出的原始结果是一个256x512的概率图后处理的目标是把这团“像素概率”提炼成小车可以用的控制指令。这个环节做得好不好直接决定了小车是否能在路上正常巡线行驶。第一步是阈值分割。将概率图按0.5阈值二值化大于阈值置255小于等于置0。这里有个小技巧阈值不要固定死在0.5可以在0.4~0.6之间调整。如果现场光线偏暗模型容易低估车道线概率下调到0.4能减少漏检反之光线过亮、路面反光多时上调到0.6能过滤一部分误检。第二步是提取感兴趣区域。虽然模型是在全图上跑的但车道线只可能出现在画面的中下方区域。源码里把图像上方约40%的区域直接置零只保留下半部分做后处理。这能显著减少后方树木、指示牌等背景干扰。有人觉得这样做会丢失远处弯道的上下文信息实际影响不大因为小车底盘低视角窄远端信息本来就不准。第三步是滑动窗口查找车道线像素。参考了经典的车道线检测思路从图像底部中心出发将下半部分图像垂直切成若干层每层用直方图统计前景像素的横向分布峰值作为该层车道线的中心位置。逐层向上扫描把这些中心点连接起来就能得到左右两条车道线的离散坐标点集。这个方案比直接做全图连通域提取更稳因为即便某一段掩码断裂滑动窗口也能依靠相邻层的统计结果把断点平滑补上。4.3 小车控制策略PID巡线与转向决策拿到左右车道线的坐标点集之后小车的控制逻辑就清晰了。核心思路是计算当前车辆位置与车道中心的横向偏差然后通过PID控制器输出转向指令。先做曲线拟合。对每个车道线的坐标点集做二次多项式拟合得到x a*y^2 b*y c的形式这里把x表示为y的函数是因为车道线的方向在图像里是纵向延伸的把y当自变量更合理。然后按y值从近到远取5个点计算左右车道线的横向中点再对这5个中点做一次平均得到当前时刻的车道中心位置。横向偏差就是图像中心点横坐标与车道中心点横坐标的差值。偏差大于0说明车偏左小于0说明车偏右。PID控制器的P系数设为1.2I系数0.01D系数0.15。这三个参数需要根据小车的响应速度实际调整没有统一标准。我实测时先给纯P控制不断加大P值直到出现震荡然后取震荡临界值的一半作为最终P值再逐步加入D来抑制超调最后用I来消除稳态误差。这个方法调整PID参数很实用比凭感觉调快得多。转弯执行方面舵机角度直接映射PID输出值。输出值限幅在-45度到45度之间超过这个范围说明车辆已经严重偏离车道需要先将车速降下来再调整方向避免高速过弯时侧翻或者冲出赛道。5. 常见问题与排查技巧实录5.1 训练阶段典型问题模型loss不下降或者下降极慢。这个现象大多出现在学习率设置不当的情况下。学习率太大loss会在某个区间震荡无法收敛学习率太小则每次下降幅度微乎其微。建议先把学习率调到1e-3快速跑10个epoch观察趋势如果loss还是不动检查数据加载环节确认掩码和原图是否对齐。我遇到过因为数据集读取时shuffle只打乱了图像路径却没有同步打乱掩码路径导致模型看到的是“这张图的像素配另一张图的标签”loss自然降不下去。验证集mIoU高但实际效果差。这类情况通常和数据分布有关。如果验证集和训练集来自同一个视频序列的连续帧模型“记住”了场景而不是“学会”了车道线识别就会出现验证指标虚高的情况。解决办法是采集数据时尽可能增加场景多样性比如不同路段、不同光线条件分别采几段混合起来做训练。训练时显存不足。最常见的原因是batch size设太大。另一个容易忽略的原因是输入分辨率把输入从256x512换成512x1024显存占用是原来的4倍不只是2倍。优先降低batch size其次降低分辨率不要一开始就更换轻量模型因为换网络结构会影响整套训练策略且效果未必能保留。5.2 部署和实跑阶段典型问题小车直线行驶没问题遇到弯道就冲出赛道。这类问题通常不是模型识别能力不够而是控制周期太长。车载端如果从摄像头取帧到控制指令下发的完整链路耗时超过100毫秒车辆在弯道处的转向响应会严重滞后。排查时先测单帧推理耗时再测整体管线延时定位瓶颈在摄像头采集、模型推理和控制计算哪个环节。一般优化方案是降低输入分辨率或者将模型导出为TensorRT尽量把单帧总耗时控制在60毫秒以内。晴天正常阴天漏检率明显上升。车道线检测在阴天容易漏检表现为掩码变得稀疏甚至断成碎片。核心原因是阴天光照均匀车道线和路面的对比度降低模型提取特征难度变大。缓解方法有两个方向一是训练时使用更强的亮度对比度增强把亮度变化范围拉大让模型见过更“恶劣”的输入二是在图像输入模型之前先做直方图均衡化提升局部对比度。实测直方图均衡化后阴天漏检率能下降一半左右。但要注意直方图均衡化不能过强否则路面纹理会被放大成伪车道线产生误检。小车在路口或者岔道口犹豫、频繁修正方向。这是因为后处理时出现了多组车道线候选滑动窗口的直方图产生了两个相近的峰值。处理方案是设定一个最小峰值距离阈值如果两个峰值太近只取较高那个太远则分别作为左右候选再按位置归并。源码里默认的峰值距离阈值是30像素如果十字路口情况频繁可以适当加大到40像素。5.3 数据与模型文件使用的避坑经验一定要先核对项目说明里数据集的划分方式再开始训练。这个项目的train、val划分是已经定好的不要把验证集图片混进训练集里否则最终效果评估会虚高部署时差距就暴露出来了。我之前疏忽过一次验证集mIoU报出95%实际跑车效果连预期的一半都不到后来排查才发现是数据泄漏了。训练好的模型文件有几种格式要注意区分.pth是PyTorch完整权重.pth.tar通常是包含优化器状态的检查点文件.onnx是跨平台推理格式。源码里加载权重时用的是torch.load然后取state_dict如果你直接拿.pth.tar当.pth加载会报missing keys的错误。解决办法是加载后只保留model_state_dict字段再送入模型checkpoint torch.load(checkpoint.pth.tar, map_locationcpu) model.load_state_dict(checkpoint[model_state_dict])另外模型训练时的输入归一化参数、图像尺寸这些预处理设置在部署时必须保持一致。很多人训练好好的部署时换了resize方式或者忘了归一化模型效果直接从95分掉到50分。这类问题通常不是模型坏了而是数据入口和训练时不一致导致的。末尾再分享一点个人体会实际跑完这个项目我最大的感受是车道线检测真正难的从来不是模型本身而是数据标注的一致性和系统的整体稳定性。你可能花两天就能把U-Net训练跑通但要把一辆小车稳稳当当地跑完一整圈赛道需要反复打磨的是后处理鲁棒性、控制参数匹配和各个模块的时序配合。建议拿到项目源码之后先把训练好的模型在单张图上做推理确认输出掩码符合预期再上小车实测。这样排查问题时能快速定位是感知环节的问题还是控制环节的问题不会两头一起抓。如果你后续想继续扩展比较推荐的方向是给模型输出增加一个可行驶区域分割分支让小车在车道线短暂缺失时也能依靠路面边缘信息保持安全行驶。这个方向在数据标注和模型结构上都和现有代码兼容度很高延展成本不大但实车可靠性提升非常明显。本文还有配套的精品资源点击获取 基于U-Net语义分割的智能小车车道线检测实战解析
简介本资源是一套面向智能小车与自动驾驶初学者、高校课程设计及科研入门者的车道线检测实战项目基于深度学习语义分割技术解决道路图像中车道线精准识别与像素级定位问题。压缩包共1554个文件含1543张标注PNG图像训练/验证用、3个核心Python脚本数据加载、模型训练与推理、1个Jupyter Notebook主程序含完整流程演示、1个模型权重.pth文件、1个README.md说明文档及5个编译字节码文件整体大小835.89MB结构清晰、模块解耦便于理解语义分割落地全流程。目前已有54人学习下载资源提供从数据预处理、UNetLane定制网络构建、端到端训练到实时检测部署的全链路实现配套文档详述环境配置、关键参数设置与常见报错解决方案显著降低复现门槛是快速掌握车道线检测工程实践的高价值开源素材。 熟悉智能小车开发的朋友应该都清楚车道线检测这个需求看起来不难但真正做起来特别容易翻车。传统CV方案换个光照就失效简单模型扛不住弯道和阴影干扰这也是为什么现在主流方案都转向了深度学习。这个项目走的是语义分割路线把每个像素分类成“车道线”和“背景”本质上是图像分割任务配合Python生态里的开源框架能在小车这种算力有限的平台上跑出稳定的检测效果。我花了一周时间把这个项目完整过了一遍从数据集整理、模型训练到部署小车实跑坑踩了不少但跑通之后的效果确实让人放心。这篇文章就把整套实现思路、关键决策和踩坑记录逐项拆开讲清楚不管是做课程设计、竞赛项目还是单纯想入门自动驾驶视觉方向都有可以直接照抄的价值。1. 项目整体设计与方案选型1.1 为什么选择语义分割而不是传统视觉方案很多刚开始接触车道线检测的人第一反应是用Hough变换配合边缘检测来找直线这个方案在结构化道路、光照均匀的环境下确实能用但实际跑起来问题非常多。比如路面有裂缝、树影斑驳、车辆遮挡Canny边缘检测会输出大量噪声点Hough变换就很难从中筛出真正的车道线。更致命的是传统方案在弯道场景几乎无解需要额外拟合曲线模型一遇到曲率变化大的路况就得重新调参数。语义分割天然适合这个场景核心原因有两个。第一它的输出是像素级分类结果模型在训练时见过的场景特征会内化为对“车道线”这个语义概念的理解而不是简单依赖边缘梯度信息去猜测因此对阴影、光照变化有天然的抗干扰能力。第二分割结果是逐像素掩码后端无论是拟合直线还是三次曲线都能直接拿像素坐标做输入不需要像传统方案那样先做特征工程再判断线型逻辑链更短误差累积更少。当然语义分割对算力的消耗比传统CV要高不少。这是选型时必须认知清楚的点你是在用算力换稳定性。但我们在小车平台上做了模型裁剪实际推理单帧耗时能控制在40毫秒以内实时性完全够用。1.2 网络结构选型U-Net为什么够用项目源码里用的是U-Net结构的变体没上DeepLabV3也没用PSPNet很多人问为什么。原因不复杂U-Net的编解码对称结构在语义分割任务里属于“性价比最高”的那种设计。编码器不断下采样提取高维语义特征解码器逐步上采样恢复空间分辨率中间用跳层连接把低级轮廓信息和高级语义特征融合在一起对车道线这种“细长连续且依赖上下文”的目标来说非常合适。DeepLabV3用了空洞卷积和ASPP模块理论感受野更大但在小车这种边缘设备上它带来的推理延迟增量会明显吃掉实时帧率性能收益却没那么明显。U-Net相对轻量配合MobileNet之类的轻量编码器在树莓派或者Jetson Nano上都能跑得动。源码里默认用的是自定义的四层下采样结构每层通道数分别是32、64、128、256参数量不大但车道线这种目标不太需要超大感受野这个规模已经够用。还有人会纠结用ENet还是U-NetENet确实更轻但它为了极限压缩牺牲了不少精度在弯道和小曲率路段表现一般。拿这个项目来说U-Net基本属于“闭眼选不会错”的方案。1.3 数据集与标注策略项目里的数据集分为两部分一部分是开源街景数据一部分是自采的路面数据。开源数据直接下载标注好的车道线掩码即可多数是TuSimple格式。但TuSimple主要覆盖高速公路场景弯道比例不高所以项目另外补充了从园区路面采集的视频帧手工标注后加入训练集。这里有个容易被忽略的问题标注的一致性。车道线的类别定义必须统一。项目里将车道线分为单类二值掩码没有区分实线虚线。因为后续后处理只需要提取中心线坐标不需要区分线型类别拆太细反而增加了训练难度和推理复杂度。如果你后续想扩展区分虚实线需要在标注时就分两个类别同时修改模型输出通道数和损失函数权重这个扩展方向项目说明里也有提到。标注工具用的LabelMe导出JSON格式后写脚本转成PNG灰度掩码图。掩码图中车道线像素值为255背景为0。训练时读入后除以255归一化到[0,1]这样二分类交叉熵损失才能正确计算。数据总量约8000张其中6000张训练2000张验证没有额外划分测试集因为部署阶段会直接用小车上采集的真实路面视频做最终验证。2. 环境搭建与数据准备2.1 Python环境与依赖版本这个项目的环境配置不算复杂但版本匹配容易出问题。实测可用的组合是Python 3.8 PyTorch 1.10.2 CUDA 11.3。PyTorch版本别随便上2.x因为项目里的部分API在2.0里做了调整旧代码需要改import路径新手很容易卡在这一步。核心依赖如下torch1.10.2 torchvision0.11.3 opencv-python4.5.5.64 numpy1.21.6 pillow9.2.0 matplotlib3.5.3 tqdm4.64.1训练时用GPU2080Ti或3060都能跑显存8GB就够。batch size设为8输入分辨率256x512大约40分钟跑完一个epoch整个训练约50个epoch两小时左右能收敛。如果手里没有GPU也能用CPU训练但一个epoch可能要10分钟以上建议直接把源码里的预训练权重拿来微调不要从头训。有个细节值得说OpenCV版本很关键。4.5.x的findContours返回值是2个到4.x后期改成2个了但早期版本会返回3个值导致解包报错。如果装了其他版本代码里的后处理部分需要按版本调整。2.2 数据集格式与预处理流程数据集目录结构如下dataset/ ├── train/ │ ├── images/ # 原始图像jpg格式 │ └── masks/ # 标注掩码png格式 ├── val/ │ ├── images/ │ └── masks/ └── test/ └── images/ # 推理时使用的未标注图像预处理流程最重要的是图像尺寸统一。源码里默认将输入resize到256x512宽x高。为什么不选正方形因为车道线的有效信息集中在图像中下方且路面在水平方向更宽256x512的矩形比例能保留更多横向空间信息让模型更好地理解车道走向。归一化参数使用了ImageNet的均值方差mean[0.485, 0.456, 0.406]std[0.229, 0.224, 0.225]。虽然这个参数是为ImageNet分类任务统计出来的但迁移到车道线分割任务同样适用因为预训练模型已经在这个分布下收敛过继续沿用能加速微调过程。Mask处理时有一个容易踩的坑直接读取灰度图时OpenCV的imread默认会以三通道读取掩码图需要强制加cv2.IMREAD_GRAYSCALE参数否则后续计算损失时形状不匹配。项目里专门封装了SegDataset类__getitem__里返回图像张量、掩码张量和文件路径后者在可视化调试时很实用能直接定位是哪张图出了问题。2.3 数据增强策略与细节这个项目里的数据增强引入了随机水平翻转、随机亮度对比度调整和随机裁剪缩放。随机水平翻转需要注意车道线位置在翻转后语义不变但如果是虚实线都标注的数据集翻转后虚实线的位置就反了需要同步翻转掩码。项目里当前只做二值分割所以翻转安全。随机亮度对比度调整这个增强对外场光线变化特别有效。小车上午跑和傍晚跑路面亮度差异很大如果不做亮度增强模型在低光环境下漏检率会明显上升。源码里通过cv2.addWeighted实现import cv2 import numpy as np def adjust_brightness_contrast(image, alpha1.2, beta15): return cv2.convertScaleAbs(image, alphaalpha, betabeta)实际使用中alpha范围设置在[0.8, 1.4]beta范围在[-20, 20]。范围太小没作用太大会让掩码目标变得模糊不清影响训练稳定性。随机裁剪缩放则通过RandomResizedCrop实现但需要保证裁剪比例不能过低否则会丢失车道线上下文。项目里scale范围设置为[0.5, 1.0]ratio限制在[1.0, 1.0]保持不变相当于只做缩放不改变宽高比。3. 模型训练核心细节解析3.1 损失函数选择交叉熵与Dice Loss的取舍语义分割最基础的损失是逐像素交叉熵。二分类场景下每个像素的预测概率和真实标签做Binary Cross-Entropy Loss然后求平均。这个损失函数本身没有太大问题但车道线有一个特殊性正负样本极度不均衡。一张256x512的图上车道线像素通常只占2%~5%背景占了绝大多数。如果直接用BCE模型会倾向于把所有像素都预测为背景因为这样损失值已经很小了。项目源码里采用了BCE Loss和Dice Loss加权组合的方式这是处理分割任务中类别不平衡问题的经典手段。Dice Loss直接从重叠度角度优化对前景区域非常敏感即使正样本很少也能给出有意义的梯度信号。公式如下import torch import torch.nn.functional as F def dice_loss(pred, target, smooth1.0): pred torch.sigmoid(pred) pred_flat pred.view(-1) target_flat target.view(-1) intersection (pred_flat * target_flat).sum() return 1 - (2.0 * intersection smooth) / (pred_flat.sum() target_flat.sum() smooth)最终损失是loss bce_loss dice_loss两者的权重是1:1。实测下来比单独使用BCE或者单独使用Dice Loss均更好。单独使用Dice Loss在训练初期会有梯度不稳定问题预测概率接近0时Dice值波动非常大而加上BCE作为“锚”能让训练过程稳定不少。3.2 训练超参数配置与优化器选择项目源码里默认的优化器是Adam学习率3e-4weight decay 1e-4。这里有一个非常关键的经验weight decay不能设太大否则U-Net解码器部分的参数会被过度正则化导致输出掩码边缘出现“锯齿感”。我之前试着把weight decay调到1e-2结果分割出的车道线边缘毛糙得没法用。学习率调度器用的是CosineAnnealingLRT_max设为50最小学习率1e-6。相比StepLR按固定步数衰减余弦退火能在训练后期保持较低学习率的同时仍然保留一些探索能力对分割任务这种高维非凸优化更友好。batch size在显存允许的情况下越大越好但也不要盲目调大。实测batch size从4调到8mIoU涨了约1.2个百分点从8调到16只涨了0.3个百分点而显存占用却翻了一倍。对边缘设备部署场景没必要追求极限精度8这个档位性价比最高。训练epoch数建议不要低于50。U-Net在30个epoch左右会开始产生明显效果但车道线这种细长目标需要更长的时间去收敛边缘细节过早停止会导致分割掩码出现断裂。源码里在训练过程中每个epoch结束都会在验证集上计算mIoU并自动保存最优权重这一步很有用防止后期过拟合时覆盖掉好的权重。3.3 评估指标与效果验证语义分割的评估指标主要看mIoU和像素准确率。项目里mIoU指标分成背景类和车道线类分别计算然后取平均。这个项目背景类mIoU通常在99%左右参考价值不大真正要盯的是车道线类别的IoU。训练好的模型在验证集上车道线IoU在83%~87%之间根据数据分布不同会有波动。评估模型时不要只看IoU还要关注预测掩码的连通性。一个很常见的现象是模型在直线路段表现很好但到了弯道路段掩码会从中段断开被截成两截或者多截。IoU指标看整体重叠度可能依然偏高但实际部署时车道线断掉了后续拟合就无法得到完整的车道曲线。所以我在验证时额外跑了一个“最大连通域面积占比”的辅助指标统计预测掩码面积最大的连通区域占全部预测前景像素的比例。这个比例低于80%就说明掩码断裂严重需要针对性调整。优化方法通常是增加数据集中弯道样本的比例或者提高输入分辨率让模型能保留更多细节这个经验在项目说明里也补充了。4. 智能小车部署与车道线后处理4.1 模型轻量化与格式转换训练好的PyTorch模型不能直接放到小车上的嵌入式环境里跑原因有两层一是依赖库体积太大树莓派这类设备上装完整版PyTorch占用空间和内存都超出预算二是推理速度不够PyTorch的CPU推理效率远不如专门优化过的推理引擎。项目里的部署方案分两条线。如果小车用的是树莓派4B或者类似Linux环境模型通过ONNX导出后用ONNX Runtime进行CPU推理。实测树莓派4B上推理一张256x512的图像大约需要80毫秒加上后处理和串口通信整条链路稳定在15~20FPS。如果小车用的是Jetson Nano模型直接转成TensorRT的engine文件FP16精度下推理一张图只需要20毫秒能跑到30FPS以上。ONNX导出代码示例如下import torch model torch.load(best_model.pth, map_locationcpu) model.eval() dummy_input torch.randn(1, 3, 256, 512) torch.onnx.export( model, dummy_input, lane.onnx, input_names[input], output_names[output], opset_version11 )导出后务必用onnxruntime做一次推理对比输出确认数值误差在可接受范围内。PyTorch转ONNX最常见的坑是某些自定义算子不支持导出但这个项目用的都是标准卷积、BN、ReLU没有这个问题。4.2 车道线后处理从掩码到坐标模型输出的原始结果是一个256x512的概率图后处理的目标是把这团“像素概率”提炼成小车可以用的控制指令。这个环节做得好不好直接决定了小车是否能在路上正常巡线行驶。第一步是阈值分割。将概率图按0.5阈值二值化大于阈值置255小于等于置0。这里有个小技巧阈值不要固定死在0.5可以在0.4~0.6之间调整。如果现场光线偏暗模型容易低估车道线概率下调到0.4能减少漏检反之光线过亮、路面反光多时上调到0.6能过滤一部分误检。第二步是提取感兴趣区域。虽然模型是在全图上跑的但车道线只可能出现在画面的中下方区域。源码里把图像上方约40%的区域直接置零只保留下半部分做后处理。这能显著减少后方树木、指示牌等背景干扰。有人觉得这样做会丢失远处弯道的上下文信息实际影响不大因为小车底盘低视角窄远端信息本来就不准。第三步是滑动窗口查找车道线像素。参考了经典的车道线检测思路从图像底部中心出发将下半部分图像垂直切成若干层每层用直方图统计前景像素的横向分布峰值作为该层车道线的中心位置。逐层向上扫描把这些中心点连接起来就能得到左右两条车道线的离散坐标点集。这个方案比直接做全图连通域提取更稳因为即便某一段掩码断裂滑动窗口也能依靠相邻层的统计结果把断点平滑补上。4.3 小车控制策略PID巡线与转向决策拿到左右车道线的坐标点集之后小车的控制逻辑就清晰了。核心思路是计算当前车辆位置与车道中心的横向偏差然后通过PID控制器输出转向指令。先做曲线拟合。对每个车道线的坐标点集做二次多项式拟合得到x a*y^2 b*y c的形式这里把x表示为y的函数是因为车道线的方向在图像里是纵向延伸的把y当自变量更合理。然后按y值从近到远取5个点计算左右车道线的横向中点再对这5个中点做一次平均得到当前时刻的车道中心位置。横向偏差就是图像中心点横坐标与车道中心点横坐标的差值。偏差大于0说明车偏左小于0说明车偏右。PID控制器的P系数设为1.2I系数0.01D系数0.15。这三个参数需要根据小车的响应速度实际调整没有统一标准。我实测时先给纯P控制不断加大P值直到出现震荡然后取震荡临界值的一半作为最终P值再逐步加入D来抑制超调最后用I来消除稳态误差。这个方法调整PID参数很实用比凭感觉调快得多。转弯执行方面舵机角度直接映射PID输出值。输出值限幅在-45度到45度之间超过这个范围说明车辆已经严重偏离车道需要先将车速降下来再调整方向避免高速过弯时侧翻或者冲出赛道。5. 常见问题与排查技巧实录5.1 训练阶段典型问题模型loss不下降或者下降极慢。这个现象大多出现在学习率设置不当的情况下。学习率太大loss会在某个区间震荡无法收敛学习率太小则每次下降幅度微乎其微。建议先把学习率调到1e-3快速跑10个epoch观察趋势如果loss还是不动检查数据加载环节确认掩码和原图是否对齐。我遇到过因为数据集读取时shuffle只打乱了图像路径却没有同步打乱掩码路径导致模型看到的是“这张图的像素配另一张图的标签”loss自然降不下去。验证集mIoU高但实际效果差。这类情况通常和数据分布有关。如果验证集和训练集来自同一个视频序列的连续帧模型“记住”了场景而不是“学会”了车道线识别就会出现验证指标虚高的情况。解决办法是采集数据时尽可能增加场景多样性比如不同路段、不同光线条件分别采几段混合起来做训练。训练时显存不足。最常见的原因是batch size设太大。另一个容易忽略的原因是输入分辨率把输入从256x512换成512x1024显存占用是原来的4倍不只是2倍。优先降低batch size其次降低分辨率不要一开始就更换轻量模型因为换网络结构会影响整套训练策略且效果未必能保留。5.2 部署和实跑阶段典型问题小车直线行驶没问题遇到弯道就冲出赛道。这类问题通常不是模型识别能力不够而是控制周期太长。车载端如果从摄像头取帧到控制指令下发的完整链路耗时超过100毫秒车辆在弯道处的转向响应会严重滞后。排查时先测单帧推理耗时再测整体管线延时定位瓶颈在摄像头采集、模型推理和控制计算哪个环节。一般优化方案是降低输入分辨率或者将模型导出为TensorRT尽量把单帧总耗时控制在60毫秒以内。晴天正常阴天漏检率明显上升。车道线检测在阴天容易漏检表现为掩码变得稀疏甚至断成碎片。核心原因是阴天光照均匀车道线和路面的对比度降低模型提取特征难度变大。缓解方法有两个方向一是训练时使用更强的亮度对比度增强把亮度变化范围拉大让模型见过更“恶劣”的输入二是在图像输入模型之前先做直方图均衡化提升局部对比度。实测直方图均衡化后阴天漏检率能下降一半左右。但要注意直方图均衡化不能过强否则路面纹理会被放大成伪车道线产生误检。小车在路口或者岔道口犹豫、频繁修正方向。这是因为后处理时出现了多组车道线候选滑动窗口的直方图产生了两个相近的峰值。处理方案是设定一个最小峰值距离阈值如果两个峰值太近只取较高那个太远则分别作为左右候选再按位置归并。源码里默认的峰值距离阈值是30像素如果十字路口情况频繁可以适当加大到40像素。5.3 数据与模型文件使用的避坑经验一定要先核对项目说明里数据集的划分方式再开始训练。这个项目的train、val划分是已经定好的不要把验证集图片混进训练集里否则最终效果评估会虚高部署时差距就暴露出来了。我之前疏忽过一次验证集mIoU报出95%实际跑车效果连预期的一半都不到后来排查才发现是数据泄漏了。训练好的模型文件有几种格式要注意区分.pth是PyTorch完整权重.pth.tar通常是包含优化器状态的检查点文件.onnx是跨平台推理格式。源码里加载权重时用的是torch.load然后取state_dict如果你直接拿.pth.tar当.pth加载会报missing keys的错误。解决办法是加载后只保留model_state_dict字段再送入模型checkpoint torch.load(checkpoint.pth.tar, map_locationcpu) model.load_state_dict(checkpoint[model_state_dict])另外模型训练时的输入归一化参数、图像尺寸这些预处理设置在部署时必须保持一致。很多人训练好好的部署时换了resize方式或者忘了归一化模型效果直接从95分掉到50分。这类问题通常不是模型坏了而是数据入口和训练时不一致导致的。末尾再分享一点个人体会实际跑完这个项目我最大的感受是车道线检测真正难的从来不是模型本身而是数据标注的一致性和系统的整体稳定性。你可能花两天就能把U-Net训练跑通但要把一辆小车稳稳当当地跑完一整圈赛道需要反复打磨的是后处理鲁棒性、控制参数匹配和各个模块的时序配合。建议拿到项目源码之后先把训练好的模型在单张图上做推理确认输出掩码符合预期再上小车实测。这样排查问题时能快速定位是感知环节的问题还是控制环节的问题不会两头一起抓。如果你后续想继续扩展比较推荐的方向是给模型输出增加一个可行驶区域分割分支让小车在车道线短暂缺失时也能依靠路面边缘信息保持安全行驶。这个方向在数据标注和模型结构上都和现有代码兼容度很高延展成本不大但实车可靠性提升非常明显。本文还有配套的精品资源点击获取