完全模型组智能车方案：从视觉识别到ROS控制的完整实践

简介来自湖北工业大学蓝电YYDS Car队的第十七届全国大学生智能汽车竞赛完全模型组完整参赛工程包面向智能车竞赛参赛者及嵌入式开发者可复现车队的工程组织与算法实现。压缩包共539个文件大小约69.67MB以C/C源码为主含262个h头文件、150个c源文件及若干hpp/cpp实现配套xml工程配置、cs/prefs等IDE设置、jpg/png图像、mp4演示录屏、md说明文档及代码工作区配置覆盖从底层驱动到上层控制策略的完整链路。已有881人浏览学习。通过本包能系统查看车队在赛道元素识别、控制策略、调试脚本与工程管理上的实际做法并参考其模块划分和关键函数实现对备赛或入门MCU开发都有很好的借鉴意义。 每年全国大学生智能汽车竞赛结束之后总会有一批优秀的工程文件在校园里流传。“完全模型组”是这几年关注度很高的赛项它和传统的竞速组、直立组最大的区别在于模型车要面对的不只是固定的赛道元素而是更像一个简化版的“自动驾驶小车”需要在复杂场景里完成识别、规划、控制这一整套闭环。第十七届比赛我们队做的是完全模型组最后拿到的成绩还行车队代号“蓝电YYDS Car”。这篇博文我就把这套方案从设计思路到具体落地再到比赛现场踩过的坑完整整理一遍给后面准备参赛的学弟学妹以及想从零开始做视觉智能车的朋友一个参考。这套系统最核心的部分并不是某一个传感器或者某一个算法而是“感知—决策—执行”三者之间的耦合关系。很多人一开始把精力全放在模型训练上结果车跑起来却东倒西歪或者识别很准但速度上不去。我先把我们队的整体设计思路拆开讲清楚这样你后面看代码、调参数时才能理解为什么要这么做。1. 整体设计思路与赛题拆解1.1 完全模型组到底在比什么完全模型组这个名称里的“完全”指的是车模本身使用官方推荐的模型车平台而不是自己搭的车架硬件限制相对固定。但它和传统摄像头组不一样赛道里不仅有锥桶、路障、横断路障还有十字路口、环岛、停车区这些元素形状和颜色也比普通赛道复杂得多。简单说赛题要求小车具备一次完整的“感知—决策—执行”能力非常接近真实自动驾驶的简化场景。我们队第一件事就是确定技术路线。官方推荐了基础平台但软件框架和算法完全自主选择。有的队用深度学习直接做端到端控制我们考虑过但最终没有采用。理由是端到端固然酷但可解释性差比赛现场出了问题很难快速定位。我们最终选择了传统视觉识别 规则决策 PID控制为主同时引入轻量级神经网络辅助做元素分类。这样既保证了速度又保证了调试效率。1.2 为什么选ROS作为软件骨架很多人觉得ROS太重跑在嵌入式板子上性能跟不上。但完全模型组不是纯单片机电控我们可以使用性能更强的计算平台。我们选ROS核心原因是它天然提供了模块间通信的机制摄像头节点、识别节点、决策节点、控制节点可以分别独立开发、独立测试。个人体会是比赛这种多人数月协作的场景模块解耦的价值远远大于那一点点通信开销。通信中间件选好之后整个系统的数据流就很清晰摄像头采集图像送入识别节点识别节点输出目标列表和自身位置估计决策节点根据这些信息生成目标速度与转向角控制节点最终把指令下发到底盘驱动。每个环节都有独立的调试工具这一点在后期的实车调参中帮了大忙。2. 核心硬件选型与软件架构解析2.1 算力平台与传感器选择了什么方案计算平台我们用了常见的AI边缘开发板属性上就是一块带GPU/NPU的小型电脑性能足够跑轻量级神经网络。摄像头方面一开始试过双目方案后来发现比赛的场景深度信息并不一定要靠双目获取单目加合理的几何假设就够用于是最后用了一颗全局快门彩色摄像头视野更稳定不会因为车体震动出现严重的果冻效应。有一个细节很多人会忽略摄像头安装高度和俯仰角。我们的车把摄像头装到离地面大约35厘米的高度俯仰角大约朝下15度。这样既能看到近处的车道线也能兼顾两三米外的锥桶。如果装得太低近处元素畸变严重太高的话远处目标太小识别模型容易漏检。这个参数是我们反复标定后确定的不同车架不同安装位置都要重新调整。2.2 识别模块用轻量网络替代大模型最开始我们直接拿YOLOv5s训练精度确实不错但在边缘设备上实时性有点紧张。后来换成了轻量化的检测网络并且做了通道剪枝和INT8量化推理帧率从不到20FPS提升到30FPS以上准确率几乎没掉。我的建议是比赛场景目标类别少、背景相对固定完全不需要上大模型轻量模型加数据增强才是正确方向。关于数据集的构建我们不是单纯依赖官方给的样本而是大量采集了现场赛道在不同光照、不同角度下的图像。这个工作量很大但非常值得。最终数据集中约七成来自自家场地实拍三成来自网络公开数据集增强经过人工清洗和标注训练出来的模型泛化性明显比只用通用数据集好很多。如果你要复现一定要记住一个原则训练数据里必须包含你们实际场地光照条件的图像否则赛场上会很惨。3. 实操过程与核心环节实现3.1 车道线检测与循迹实现细节车道线检测是实现稳定跑图的基础。我们采用的方法是图像预处理灰度化、高斯模糊、边缘提取→ 感兴趣区域裁剪 → 透视变换 → 滑动窗口搜索车道线像素 → 拟合二次多项式。透视变换是花费时间最多的环节。变换矩阵选哪些点直接决定后续曲线拟合的准确性。我们选的是相机画面中近处两条车道线的四个边界点映射到一个固定宽高的俯视图中。调试时我习惯用调试工具实时显示变换前和变换后的图像叠加车道线拟合结果这样能快速确认矩阵是否准确。最终控制时我们根据拟合曲线计算当前车辆相对车道中心的横向偏差和航向偏差作为PID控制器的输入。一个小技巧PID参数不要一开始就在整车上调先架起后轮让车悬空只让转向机构响应观察是否出现振荡。但要注意这个空载状态和地面状态差异很大悬空微调只能解决方向响应问题最终的P、I、D参数还是一定要放到地面上实际跑。地面摩擦和轮胎抓地力对转向动态影响极大跳过这个步骤会多走很多弯路。3.2 元素识别与减速决策策略比赛场景里最常见的三个元素是锥桶、路障和横断路障。我们的策略不是对每个元素都做完全不同的处理而是统一成“障碍物类目标 减速标志类目标”两种行为类型。锥桶用检测框中心坐标加宽高信息估算它的距离路障和横断路障因为形状统一直接用分类网络区分。决策逻辑用状态机实现正常循迹状态 → 检测到障碍物 → 进入减速状态同时根据目标在图像中的横向位置决定微小避让方向 → 通过障碍物后恢复循迹状态。这里要特别注意的是减速不能太猛否则车身重心转移会导致转向不足尤其是在连续弯道遇到路障时极易冲出赛道。我们调试中发现针对路障的减速距离经验值大约在1.2米到1.8米之间比较合适。太早减速影响圈速太晚减速容易来不及。这个参数和最高车速强相关如果最高车速设到3m/s以上减速距离就要相应拉长需要反复实测。3.3 环形赛道与十字路口的特殊处理环岛和十字路口是很多队伍翻车的地方。我们采用的方案是维护一个简单的赛道拓扑逻辑通过识别到的元素类别和车体当前的姿态判断当前处于十字路口还是环岛入口然后切换对应的转向策略。环岛策略的难点在于出口的判断。我们利用环岛内部斑马线区域作为出口信号当检测到斑马线出现并持续数帧后才认为可以出环。这里必须有帧数确认机制因为单帧噪声会导致提前出环。我们设置的是连续5帧检测到出口标志才动作实测下来可靠性很高。十字路口则简单一些主要靠车身磁罗盘数据和陀螺仪积分来判断大致方向。但要注意陀螺仪零漂会随时间累积长时间跑下来会偏所以我们的做法是每次检测到起跑线时用起跑线的方向做一次全局角度校正。这个策略保证三圈以上的长跑测试方向不会漂移。4. 常见问题与排查技巧实录4.1 模型训练准但实车识别差怎么办这个是最常见的问题也是我们第一版方案栽过的坑。训练时测试集准确率高达95%到了实际赛道上掉到70%都不到。原因基本出在数据分布不一致上。解决办法一是增加现场实拍数据占比二是做数据增强时加入亮度扰动、高斯噪声、运动模糊和随机裁剪。特别是运动模糊因为赛道里高速运动场景很多没有模拟过模糊的模型动态识别能力确实差很多。另一个容易被忽略的细节是摄像头白平衡。不同时间段的自然光色温差异非常大。我们后来在代码里加了自动白平衡并且模型训练时把RGB通道做了归一化增强模型的色彩鲁棒性一下子提升了很多。4.2 实车运行中偶发抖动和异响车跑起来有时候会出现方向盘小幅抖动车轮部位嘎吱响。这类问题通常不在算法而在机械结构。先是检查转向机构球头有没有松动然后是舵机臂和拉杆的虚位。模型车本身精度有限跑久了螺丝很容易松动每次训练前扭一遍关键螺丝是基本操作。如果机械没问题那大概率是PID中D项过大。D项过大的典型表现是高频小幅振荡尤其在直线高速段格外明显。我们把微分项从0.8降到0.3左右配合一点低通滤波抖动立刻就好了很多。不要迷信拉高D能提升响应速度比赛车对稳定性要求远大于响应速度。4.3 算力占用过高导致偶发卡顿边缘设备的算力有限识别、决策、通信、显示同时跑很容易出现卡顿卡顿几帧对控制来说就是灾难。我们最后做了一次彻底的软件瘦身识别节点和决策节点之间的图像传输只传压缩后的JPEG不再传原始BGR图像显示窗口只在调参模式开启比赛模式全部关闭模型推理时锁定CPU和NPU核心避免被其他进程抢占。最终实车运行时的CPU占用率从85%降到了40%上下帧率稳定在30FPS。如果你也遇到卡顿先不要急着换硬件把系统里每个节点的耗时打点统计一下往往能发现某个节点在疯狂占用资源。5. 从备赛到比赛的几个关键时间节点5.1 备赛前两个月该完成什么备赛节奏很重要。我强烈建议赛前两个月的节点车至少能稳定完成一圈完整赛道哪怕速度很慢。因为后面所有优化都是建立在“你已经有一台能跑完全程的车”这个基础之上的。很多队伍前两个月还在反复调识别准确率导致后面没有时间做长距离稳定性测试结果比赛时跑两圈就出问题。前一个半月重点做元素的专项测试把每个元素的识别阈值、距离参数都记录成表格。这个表格非常有用比赛前可以直接对照检查不会因为紧张忘记参数。5.2 比赛现场的快速应急策略现场环境往往和训练场地不同光线、地毯材质、赛道摩擦都会变。我们到赛场后的第一步不是急着跑而是携带电脑在赛道边采集一圈图像用当天数据快速做一次模型微调只训练10到20个epoch就够了。这个方法帮我解决了现场光线不适应的很大一部分问题。另外现场一定要带齐备用螺丝、扎带、热熔胶和充电器。比赛检修时间往往很短现买根本不现实。还有赛前把所有配置文件备份到U盘和网盘曾经亲眼见过有队伍电脑坏了、配置全丢只能临时重新调参的情况。5.3 团队协作与代码版本管理这个说多了都是泪。我们队早期没有用代码版本管理各改各的结果有一次把别人调试好的参数覆盖了找了一整天才恢复。后来强制使用Git管理每人的分支独立合并前必须跑一遍仿真或场地测试。配置文件和参数文件也纳入版本管理谁改了什么东西一清二楚。“蓝电YYDS Car”这个名字其实也寄托了我们的心态——年轻人做技术要有点自嘲和趣味但追求极致的决心不能少。6. 给小白的入门路线建议如果你是完全零基础不要一上来就想着深度学习、端到端。我的建议路径是先把PID调好让车能沿着一条直线稳定跑再做一个最简单的OpenCV循迹让车能在白色背景黑色线条的模拟跑道上跑起来然后再加入检测网络最后再上ROS完整架构。很多人觉得前面步骤“太低级”直接跳到最后一步结果发现基本概念都不清楚出了问题根本无从下手。技术这东西很难跳级每层都有每层的坑老老实实走一遍反而是最快的路径。第二个建议是一定要学会看懂调试曲线。我们的上位机软件可以实时显示图像检测结果、拟合曲线、PID输出量和速度反馈。建议所有调参都基于数据而不是“感觉”。我自己见过太多人盲目调参调了一个下午最后发现是电机驱动板供电不足根本不是软件问题。先检查硬件再调软件这是基本的工程素养。7. 结语一些实际体会我做这个项目最大的感触是比赛成绩固然重要但更重要的是它逼着你把“能跑”变成“跑得稳”再把“跑得稳”变成“出了问题三分钟能定位到具体模块”。这个工程化思维是课堂上学不到的。你可能会在深夜十一二点还在调车道线、测阈值会在比赛前一天对着一个莫名其妙的bug崩溃但等它终于稳定跑完全程的时候那种成就感确实非常真实。最后再分享一个小经验每一次对参数或者代码做出修改不要只记录“改了什么”要记录“为什么改”和“改完以后效果怎么样”。这份修改日志不仅帮你避免重复踩坑还能在答辩时提供非常清晰的技术演进脉络这也是评委很喜欢看到的东西。希望这篇整理能帮到在准备完全模型组的你。我们赛场见。本文还有配套的精品资源点击获取