“如果只看表面智能车竞赛拼的是算法够不够新、代码写得好不好。但真正跑完最后一趟车你就会明白决定你能不能站上领奖台的往往是实验室里那些没人愿意记录的脏活线松了、供电不够、陀螺仪飘了、PID 调了一晚上车还是在原地转圈。”这篇内容想写给两类人。一类是正在备赛、每天被赛道折磨的同学另一类是明年甚至后年才第一次接触全国大学生智能车竞赛、想提前搞明白这事到底值不值得投入的“萌新”。它既是一场和竞赛的告别也是一份可以照着做、照着避坑的技术笔记。文章不会只讲情怀也不会只堆代码。后面会从竞赛的底层逻辑、赛前准备、整车架构一直写到调参、图像处理、技术报告和常见问题排查。你可以把它当成一篇经验贴来读也可以当成一份简化版的备赛手册来收藏。1. 为什么写下这篇文章最后一届智能车到底留下了什么关于全国大学生智能车竞赛每年都在更新规则组别越来越多传感器方案越来越丰富。但从第20届、第21届的热度来看有一个趋势没有变关注这个比赛的人越来越多每年技术报告和国赛名单的搜索量都很高。这意味着什么意味着竞赛的“技术门槛”正在被更多人跨过但也意味着“认真准备”和“跟风报名”之间的差距会被拉得越来越大。2026年的夏天对即将告别竞赛的作者来说是最后一届。所谓“最后一届”不只是说比赛名额用完、毕业临近而是说一个完整的竞赛周期即将结束。从不知道电感是什么到能徒手把摄像头支架改短三毫米从对着 PID 公式发呆到闭着眼睛能说出增量式 PID 和位置式 PID 的应用场景从第一次把车放到赛道上的手忙脚乱到最后一晚调完参数后安静地看车跑完一整圈——这些变化才是竞赛真正留下的东西。这篇文章的价值不在于记录某一次比赛的成绩。而在于把“最后一届”的经验压缩成文字让后来者少走一些弯路。竞赛最廉价的成本是买零件最昂贵的成本是时间。如果你的备赛周期只有几个月那么搞清楚“哪些环节最重要”比“哪个传感器更贵”重要得多。下面从技术角度把智能车竞赛真正要面对的问题拆开讲。2. 智能车竞赛的底层逻辑它到底在比什么很多人对智能车竞赛的第一个误解是它比的是谁的算法更“高级”。其实不是。全国大学生智能车竞赛的看点是一辆小车在赛道上能多快、多稳地跑完。无论是竞速组还是创意组核心评价维度都是“系统稳定地完成任务”。换句话说你的车可以不用最前沿的算法但必须能在比赛那几分钟里稳定输出。很多队伍在实验室里跑得很好一到赛场就翻车不是因为算法被对手碾压而是因为系统鲁棒性不够。从最近几届的竞赛信息来看比赛通常按传感器方案或任务类型分为多个组别例如常见的摄像头组、电磁组以及结合语音、视觉等任务的创意组。规则每年会调整所以备赛之前第一件事不是买摄像头而是把当年竞赛规则反复读三遍。规则决定了技术路线比如电磁组主要靠电感采集赛道磁场信息摄像头组靠图像识别赛道边界创意组则可能要求识别特定标志物或完成特定动作。技术路线不同硬件方案、软件架构和调试方法都完全不同。技术报告也是竞赛评分里很关键的一环。每支参赛队伍都要提交技术报告里面要写清方案选型、系统设计、算法原理、调试过程和数据对比。从历年搜索热度看“智能车技术报告”一直是被搜得最多的关键词之一说明很多人不知道报告怎么写。这里提前给一个结论技术报告不是比赛结束后的流水账而是贯穿整个备赛周期的工程文档。写得好不好直接影响最终成绩。所以智能车竞赛比的其实是三件事系统设计能力、工程调试能力、技术表达能力。算法只是其中一环不是全部。3. 赛前准备组队、选组与第一笔预算3.1 组队三个人不是越多越好智能车竞赛通常要求团队协作但三个人不是越多越好。核心角色有三个硬件负责人、软件负责人、调试负责人。三个人可以重叠但有一个原则必须坚持——每一个模块都要有明确的人负责。如果三个人都去改 PID最后一定会有一个人在失控的边缘反复横跳。更务实的建议是队伍里至少要有一个愿意调硬件的人。很多问题的根源是接触不良、供电不稳、机械结构松动这些不是靠改代码能解决的。如果一个队伍全是“代码强者”那大概率会卡在硬件玄学上。3.2 选组不要只看别人的成绩选组之前先问自己一个问题队伍里最擅长什么如果对图像处理感兴趣有OpenMV、摄像头、图像处理基础摄像头组是主流方向。如果更擅长模拟电路、信号采集和滤波电磁组是一个硬件门槛适中、调试反馈直观的组别。如果是创意方向并且团队有算法、语音或视觉方面的积累可以考虑规则里对应的创意组。需要提醒的是选组不是选“哪个组容易获奖”而是选“哪个组适合自己队伍的条件”。每年竞赛规则都会变不同组别的热度也不一样。但从综合情况来看完成度高的队伍比选一个“冷门”组别的队伍更容易出成绩。一个做了一半的创意组并不比一个稳定完赛的竞速组更占优势。3.3 预算第一笔钱花在哪第一笔预算不要全砸在昂贵的传感器上。基础方案一般是主控板、电机驱动、编码器、电源模块、传感器模块、车模、电池、调试工具。真正应该多花钱的地方是调试工具和备用零件。竞赛圈有句老话“电池不是消耗品是凶器。”这里不是讲危险而是说电池必须多备两块并定期检查电压和放电能力。很多“跑着跑着突然复位”的问题最后查下来都是电池电压瞬间跌落导致单片机复位。类似的教训还有很多后面在常见问题部分会专门展开。4. 整车系统架构与软硬件分工4.1 系统模块从系统角度拆解一辆智能车可以分成四个层次感知层摄像头、电磁传感器、陀螺仪、编码器等负责采集赛道和环境信息。决策层主控芯片运行图像处理算法、控制算法、状态机逻辑。执行层电机驱动、转向舵机或差速机构根据决策结果控制车身运动。电源层电池、稳压模块、降压电路为所有模块提供稳定的电压。这四个层次里的任何一环出问题车都跑不稳。很多队伍调试时只盯着决策层的算法却忽略了感知层的供电和电源层的稳定性。这是新手最常走进的死胡同。4.2 主控选型主控选型以“够用”和“团队熟悉”为原则。使用最广泛的方案是 STM32 系列资料多生态成熟坑也已经被踩平了。如果你所在实验室有更熟悉的其他平台也不是不能用但要保证遇到问题时能快速找到相关资料。需要提醒的是主控不是越贵越好。算力高的主控意味着开发复杂度也高如果团队的能力匹配不上反而会成为负担。竞赛比的不是芯片型号而是整车的稳定完成度。4.3 软件框架软件框架建议分成以下几层main.c —— 主循环调用各模块的初始化与任务调度 init.c —— 初始化 GPIO、定时器、串口、传感器、编码器 control.c —— PID 控制逻辑速度环、转向环 sensor.c —— 读取摄像头/电磁/陀螺仪/编码器数据 image_process.c —— 图像二值化、赛道边界提取、赛道元素判断 debug.c —— 串口输出、参数在线调整分层的目的是让不同成员可以并行开发、独立调试。比如硬件负责人可以先写好 sensor 层软件负责人去写 control 层调试时通过串口把各层数据打出来定位问题会非常快。这里给一个最简化的主循环示例文件路径可以放在src/main.c// 文件路径src/main.c #include init.h #include sensor.h #include control.h #include debug.h int main(void) { // 第一步系统初始化 System_Init(); // 第二步开启串口调试 Debug_Init(); while (1) { // 第三步采集传感器数据 Sensor_Update(); // 第四步根据传感器数据计算控制量 float speed Speed_Calculate(); float steer Steer_Calculate(); // 第五步执行控制 Control_Apply(speed, steer); // 第六步调试输出方便观察关键数据 Debug_Output(speed, steer); } }这个示例不是完整可运行的工程但它给出了一个清晰的软件骨架。重点在于主循环不能做阻塞式等待。如果在主循环里用delay等待传感器数据整车的控制周期会变得不稳定车速一快就必然出问题。正确做法是用定时器中断或 DMA 方式采集数据主循环只负责计算和执行。5. 调参实战从能跑到跑稳的核心技巧5.1 先调速度环再调转向环很多队伍的第一辆“能跑”的车都是在调参第 N 次之后才实现的。调参的核心顺序是先让车能直线跑再让车能拐弯。连直线都跑不直的参数直接上弯道只会让问题更复杂。建议先关闭转向控制只给一个固定的转向量让车在直道上测试速度环的稳定性。速度环的目标是“给定速度后编码器反馈速度波动尽量小启动和停止不振荡”。等直线速度稳定之后再开始调转向环。转向环调好后再合在一起跑弯道。5.2 增量式 PID 实现下面是一个通用的增量式 PID 实现适用于速度环或转向环。这个代码只做演示重点是理解公式和数据结构。// 文件路径src/control.c typedef struct { float target; // 目标值 float feedback; // 反馈值 float error; // 当前误差 float last_error; // 上一次误差 float integral; // 积分累计 float kp; // 比例系数 float ki; // 积分系数 float kd; // 微分系数 float output; // 输出值 float output_max; // 输出限幅 } PidObject; float PID_Incremental_Calculate(PidObject *pid, float target, float feedback) { pid-target target; pid-feedback feedback; float error target - feedback; float p_term pid-kp * (error - pid-last_error); float i_term pid-ki * error; float d_term pid-kd * (error - 2 * pid-last_error pid-last_last_error); pid-output p_term i_term d_term; if (pid-output pid-output_max) { pid-output pid-output_max; } else if (pid-output -pid-output_max) { pid-output -pid-output_max; } pid-last_last_error pid-last_error; pid-last_error error; return pid-output; }增量式 PID 的特点是不直接输出绝对值而是在上一次输出上做增量调整。它天然带有“记忆”效果适合电机、舵机这类执行机构。要注意的是积分项不能无限制累加所以上面代码中加了output_max限幅这是工程上必须有的保护。5.3 调参顺序与误区调整目标先调什么再调什么观察标准速度环PI必要时 D编码器反馈和目标速度偏差小启动无明显抖动转向环PD最后 I弯道切入准确直道不抖动整车稳定性机械结构供电稳定高速行驶时无复位、无抖动最常见的调参误区有两个。误区一只盯曲线不看车。意思是只关注上位机软件里显示的 PID 曲线而忽略了小车的实际姿态。曲线是辅助手段车在赛道上的实际行为才是最终判断标准。跑起来 “姿态丑但稳定” 的车往往比 “曲线漂亮但压线” 的车更有价值。误区二一次调两个环。改速度环参数的同时还去动转向环参数一旦出了问题根本不知道是哪个环引起的。正确做法是每次只改一个参数改完跑一圈记录数据再改下一个。调参这个环节慢就是快。6. 赛道元素识别与图像处理要点6.1 摄像头组的图像处理摄像头组是每年参赛人数较多的方向之一。图像处理的核心任务是把摄像头采集到的赛道图像转换成车能理解的信息——通常是赛道边界和中线。一个经典的做法是图像二值化把灰度图变成黑白图然后按行扫描寻找赛道边界。// 文件路径src/image_process.c // 简化示例根据灰度阈值进行二值化 #define IMG_W 160 #define IMG_H 120 #define THRESHOLD 128 uint8_t binary_image[IMG_H][IMG_W]; void Image_Binary(uint8_t gray_image[IMG_H][IMG_W]) { for (int row 0; row IMG_H; row) { for (int col 0; col IMG_W; col) { if (gray_image[row][col] THRESHOLD) { binary_image[row][col] 1; // 白色赛道或背景 } else { binary_image[row][col] 0; // 黑色边界 } } } }这里只是二值化的最基础版本。实际工程中阈值不会固定不变因为不同光线条件下的赛道亮度差异很大。更实用的方案是动态阈值或自适应阈值根据图像前几行的灰度分布来调整二值化阈值。如果你的车在新的光线环境下突然找不到线了第一反应应该是阈值需要调整而不是算法写得有问题。6.2 电磁组的采集与滤波电磁组靠电感采集赛道中心的磁场强度来判断车相对赛道中心的位置。电感信号容易受到电机、电源电路和外界电磁环境的干扰所以滤波是电磁组绕不开的环节。常用的方案有滑动平均滤波、一阶低通滤波、卡尔曼滤波等。滤波不是越复杂越好而是要看信号带宽和实时性要求。滤波后信号平滑了但响应变慢不滤波响应快但噪声大。这个平衡要靠实验数据来定。6.3 赛道元素状态机十字路口、环岛、坡道、断路、障碍等赛道元素是比赛能不能拿好成绩的分水岭。处理这些元素推荐使用状态机而不是在图像处理里一股脑加判断条件。状态机的基本思路是把车的状态分成“直道”、“入环”、“环内”、“出环”等阶段每个阶段有独立的处理逻辑状态之间通过明确的标志位切换。比如进入环岛前图像里会观察到左侧边界消失、右侧边界连续此时切入“入环”状态执行对应的转向策略当图像恢复正常的双边界时再切回“直道”状态。状态机的优势是逻辑清晰、容易调试遇到问题也知道是哪个状态没切回去。需要强调的是处理赛道元素的代码一定要在比赛前反复验证“误判”的情况。很多队伍不是识别不了元素而是在直道上误触发了环岛逻辑导致车在平路上突然猛打方向。这种“假阳性”比识别不到元素更可怕。6.4 图像处理调试的必备手段串口输出是调试的基础但光看数字还不够。更高效的调试手段是图像上位机——把摄像头采集到的原图、二值图、提取到的边界线都实时显示在电脑上。通过图像上位机你可以快速判断是二值化阈值的问题还是边界拟合逻辑的问题。哪怕是电磁组也建议把采集到的电压值、滤波后的曲线、计算出的偏差值实时打印出来观察它们在弯道和直道上的变化趋势。7. 技术报告与工程素养代码之外的隐形分数如果你只把智能车竞赛当成“把车调快”最后一定会吃亏。因为技术报告在竞赛计分里占据重要位置。从历年情况看很多队伍车跑得不错但技术报告写得潦草最终分数被拉低非常可惜。技术报告的核心不是“写论文”而是把工程过程讲清楚。要让评委看完之后明白为什么选择这个主控、这个传感器方案关键算法的原理是什么遇到过什么问题怎么解决的最终参数是怎么定下来的数据对比是什么。写技术报告最容易犯的错是“只写结论不写过程”。比如只写“经过反复调试我们最终将速度环 P 设为 12”却没有说明为什么从 8 调到 12、中间发生了什么现象、调完以后车速提升了多少。这类写法在评委眼里等于没有写。推荐一个通用结构系统总体方案设计画出系统架构说明分工。硬件设计与选型包括电源方案、传感器布局、机械改装。软件算法设计包括图像处理、控制算法、状态机逻辑。调试过程与数据分析用表格和曲线说明参数变化和效果对比。总结与改进方向客观说明不足不写假大空。工程素养还体现在版本管理上。建议从备赛第一天就用 Git 管理代码用 Excel 或卡片记录每天的调参数据。不要等到比赛前一周才从一堆test_final_v7.c文件里找哪个是能跑通的版本。竞赛现场最怕的不是代码慢而是你不知道自己改了什么导致车突然不能跑了。8. 常见问题与排查方法下面的问题是几乎所有队伍都会遇到的典型问题整理成表格方便你直接对照排查。问题现象可能原因排查方式解决方案车跑着跑着突然复位电池电压跌落单片机供电不稳定用万用表/示波器观察运行时电源电压波形检查电池健康度加稳压电容更换稳压模块摄像头图像花屏或闪烁摄像头排线接触不良或供电不足用手按压排线观察画面变化检查摄像头供电电压重新插拔排线使用屏蔽线或缩短排线长度单独给摄像头稳压供电电机抖动明显速度不稳PID 参数过大或反馈信号噪声大打印编码器反馈值观察振动频率与 P 值关系降低 P 值或对编码器信号加滤波处理直道上车左右摆头转向环 P 过大或机械结构松动让车在直道匀速行驶观察转向舵机响应降低转向 P检查舵机连杆松动点电磁组信号跳变严重电感线未屏蔽或电机干扰耦合用示波器观察电机启动时电感波形使用屏蔽线正确接地加滤波电容或软件滤波车在弯道切内线压到赛道边界转向响应太慢或前瞻距离不够查看上位机图像中边界提取位置提高转向环响应速度调整摄像头前瞻距离技术报告被评委质疑“看不懂”只写结论不写过程逻辑不完整让队友以外的人通读报告并提问补充数据对比、公式推导和调试过程记录这里的排查思路本质是“先硬件后软件先供电后算法”。很多问题看起来像算法问题最后查出来都是硬件接触不良或供电不足。特别是摄像头花屏、单片机偶发复位、电机突然一顿一顿这三个现象90% 的概率出在电源或接线而不是代码。9. 给下一届真正有用的五条建议作为告别赛的总结最后这五条建议不是从获奖名单里总结出来的而是从无数个“为什么又不行了”的夜晚里提炼出来的。每一句都有实际场景对应。第一把技术报告当成工程日志来写而不是比赛后才补的作业。从第一天开始每周记录做了什么、改了什么参数、跑了什么效果。比赛前整理技术报告时你会感谢自己当年的记录习惯。第二规范命名和版本管理。不要在桌面上新建1111.c、2222.c、最终版.c。建立v1.0、v1.1这样清晰的版本号每次修改前先提交一份可运行的稳定版本。这样一旦改坏了可以快速回滚而不是在代码里“考古”。第三调参一次只动一个变量。把参数调参变成“对照试验”而不是“玄学调参”。哪怕你改完以后觉得效果挺好也要记下来。等到后面把车跑崩了你才知道是哪个参数导致的问题。第四重视硬件检查和供电设计。检查电源模块的输出纹波检查每一根杜邦线的插接状态检查电池在负载下的压降。硬件不稳定的队伍代码写得再漂亮都是空中楼阁。第五保持记录失败的习惯。竞赛最宝贵的财富不是最终跑出来的那几秒成绩而是那些失败的调试记录。它们才是你真正理解竞赛的入口。不要怕记录“今天车又跑崩了”因为三个月后你会发现当年记录的每个“崩”都是后来解决问题的线索。26 年的夏天总会过去最后一届智能车也总会跑完最后一圈。但那些在实验室里和队友一起改代码、调参数、对着赛道发呆的晚上会以另一种方式留在你的工程直觉里。希望这篇内容能让下一届的同学少走一些已经被人走过的弯路。愿你们在夏天的赛道上跑得尽兴也跑得明白。