26 年的夏天我交出了最后一辆智能车的钥匙。从大二第一次踏进实验室到国赛名单公布那天在屏幕前反复刷新页面很长一段时间里这辆车的每一个螺丝、每一行代码、每一次赛道上的飞驰都占据着我生活的重心。这篇文章不是获奖感言也不是情绪化的告别。我想把它写成一份能真正复用的技术复盘关于规则解读、硬件选型、软件框架、调参方法、技术报告写作也关于一个老队员如何把踩过的坑、验证过的流程、失败过的经验完整地交接给下一届队员。如果你正在准备全国大学生智能车竞赛或者你刚刚接手实验室的传承任务这篇文章可以直接收藏。下面我会按备赛的时间线从规则研读讲到技术报告再从调试方法论讲到团队协作尽量把能写成清单的内容都写成清单把能提前避开的坑都标出来。1. 核心信息速览先给一张总表方便你快速判断这篇文章包含什么以及智能车竞赛备赛这件事的整体框架。注意竞赛规则每年都会调整以下内容属于通用的备赛方法论具体条款一律以当年官方发布的竞赛章程和规则文档为准。项目类型全国大学生智能车竞赛备赛经验、技术复盘与团队交接指南适合读者准备报名参赛的本科生、实验室新队员、负责带队的老队员、指导老师备赛周期通常为一个完整赛季从规则发布到分区赛/国赛结束具体以官方日程为准核心知识栈嵌入式 C/C、单片机或 MPU 主控开发、传感器采集与处理、电机与舵机控制、PID 控制、图像处理或电磁信号处理主要输出物可稳定完赛的赛车、完整技术报告、调试记录、代码仓库、交接文档常见失败原因机械结构松动、供电不稳、代码边界条件遗漏、临场环境变化、调参没有留版本记录关键时间节点规则发布、组队报名、技术报告提交截止、分区赛、全国总决赛名单公布、全国总决赛合规提醒遵守竞赛规则与学校实验室管理规范注意用电与电池安全技术报告必须原创并规范引用从上表能看到智能车竞赛不是单纯的编程比赛也不只是硬件焊接比赛。它是一条完整的工程项目链路规则理解、方案选型、机械组装、嵌入式开发、算法调试、稳定性测试、文档沉淀最后才到赛场上的那一趟飞驰。任何一个环节断了车都跑不远。2. 备赛路线总览从规则发布到国赛名单先把这个赛季的完整节奏放出来。很多队伍失败不是因为技术不行而是因为时间安排不合理。比如前期花太多时间在研究复杂算法上结果车连直线都跑不稳或者最后一个月还在大改机械结构导致完全没有时间验证稳定性。阶段核心任务主要风险建议收尾标志规则研读确定组别理解赛道元素、判罚规则、允许的硬件范围规则理解偏差选错组别输出一份规则要点文档硬件选型与搭建车模组装、传感器安装、电源设计、走线固定供电不稳、机械虚位车能上电自检并跑直线软件框架主控初始化、传感器采集、控制循环、调试接口代码耦合混乱跑通“采集-处理-控制”闭环算法调试PID 调参、图像/电磁数据处理、速度规划调参效率低改来改去没有记录同一赛道连续完赛 10 圈稳定性打磨多场地测试、光线/电磁环境变化、长时间运行只在实验室跑得稳在陌生场地保持较高完赛率技术报告与答辩整理方案、设计过程、实验数据、对比分析数据缺失补图困难报告初稿完成数据完整实战模拟按比赛流程模拟发车、故障恢复、排队等待临场紧张、操作不熟模拟流程走通两遍更稳妥的判断是把整个赛季按“4 个月搭好车、2 个月调稳定、1 个月写报告”来规划具体时间根据课程安排浮动。前面基础打得越扎实后期越不会出现推倒重来的情况。3. 规则解读读不懂规则后面全是白干智能车竞赛最容易被低估的环节就是规则研读。每一年规则发布后都会有一批队伍因为对赛道元素理解不准确导致机械结构、传感器布局甚至算法架构选错方向。3.1 规则文档应该怎么读建议拿到规则文档后按以下顺序处理先看组别设置。 每一届通常会有多个组别不同组别对传感器、车模类型、赛道元素的要求不同。先确定自己的技术储备适合哪个组再决定投入方向。再看赛道元素表。 元素是固定的还是随机的是直道、弯道、十字、坡道、环岛还是更复杂的障碍物直接决定传感器布局和控制策略。重点标出判罚条款。 比如出界怎么判、是否允许人工干预、停车位置是否有要求。这些条款决定了你的车是“求稳”还是“求快”。确认硬件限制。 哪些传感器允许用、哪些主控平台算力受限、是否允许无线调试这些信息对成本预算和开发计划影响很大。查往年技术报告和公开答疑。 很多规则细节在文档里写得不明确但往年报告和官方答疑里会有更具体的解释。这里要特别提醒不要把上一届的规则当成这一届的规则。智能车竞赛的赛道元素和规则几乎每年都有调整以官方最新发布的规则文档为准是所有工作的前提。3.2 规则理解偏差会导致什么问题最常见的问题有三个传感器布局选错。比如组别允许摄像头但规则限制安装高度导致视野范围不足后期只能推翻重装。控制策略过于激进。规则要求在特定区域减速或停车但队伍没有留出足够的安全裕量结果高速状态下处理不及时直接出界。忽略判罚细节。有些队伍整车性能很好却因为停车位置不对、发车姿态不符被扣分非常可惜。4. 硬件平台搭建先追求“能稳定走”再追求“快”硬件是智能车的地基。很多算法问题归根结底是机械结构和供电问题。车跑着跑着突然抖动大概率不是 PID 参数的问题而是某个螺丝松了或者轮胎磨损不一致。4.1 车模机械组装车模的机械结构直接影响控制精度。组装时要注意以下几点转向机构检查虚位。舵机通过连杆驱动前轮转向如果连杆虚位太大转向响应会失真后期 PID 怎么调都调不出理想效果。悬挂与底盘保持左右对称。左右轮距不一致、底盘倾斜都会导致直线行驶跑偏。轮胎状态轮胎磨损后抓地力变化明显建议准备备用轮胎并在赛前适应新轮胎的特性。螺丝紧固每次下地测试前巡检一遍关键螺丝。比赛中途掉螺丝是真实发生过的低级事故。4.2 主控与传感器选型具体的主控芯片型号每年都会更新这里不展开推荐具体型号只强调评估三件事算力是否满足算法需求。 如果组别允许视觉处理主控算力太弱会导致图像帧率不足进而影响控制实时性。外设接口是否够用。 要接几个编码器、几个传感器、是否需要无线调试模块这些都要提前规划好引脚。开发环境是否成熟。 选择社区资料多、调试工具完善的平台遇到问题的解决成本会低很多。如果团队都是新手不建议选过于冷门的平台。传感器方面不同组别差异很大常见的有摄像头、电磁传感器、激光雷达等。但无论哪种传感器都要注意安装稳固、抗干扰、便于调试。摄像头要防止振动导致画面抖动电磁传感器要远离电机和电源线的干扰源。4.3 电源与供电设计供电是整个硬件系统里最容易出问题、也最容易被忽略的部分。用稳压模块给主控和传感器单独供电避免电机启动瞬间拉低电压导致主控重启。在电源输入端加大电容吸收瞬间压降。电池电量变化对性能影响很大。满电和低电时的车速、舵机响应都不一样所以训练和比赛尽量在相近电量下进行。所有接线都要做防松处理可以用热缩管、扎带或者点胶固定。比赛中振动很大一根线松了就可能整车断电。4.4 硬件自检清单每次下地测试前建议养成习惯花两分钟过一遍这个清单检查项检查内容处理方式电池电压是否在正常工作范围低电量及时更换或充电电机与舵机线插头是否松动、线皮是否破损重新插紧并固定传感器固定摄像头支架或电磁支架是否松动重新紧固螺丝轮胎与底盘是否有异物卡住、螺丝是否松脱清理并紧固主控指示灯是否正常亮起、有无异常报警查看日志或串口输出5. 软件框架与数据流把代码写成能调试的系统很多队伍的车一开始能跑后面越改越乱就是因为代码没有一个清晰的框架。传感器采集、数据处理、控制决策、电机输出全都堆在一个 while 循环里改一处就可能影响全局。5.1 建议的数据流架构一个通用的智能车软件架构可以分成四层传感器采集层 - 数据处理层 - 控制决策层 - 执行输出层传感器采集层负责获取摄像头图像、电磁信号、编码器数据等原始信息。数据处理层对原始数据进行滤波、二值化、特征提取输出“赛道中线在哪里”“当前速度是多少”这样的中间结果。控制决策层根据中间结果计算转向量和目标速度。执行输出层将控制量转换成舵机和电机的具体输出。每一层之间通过结构体或接口函数传递数据尽量做到“上层不关心底层怎么采集底层不关心上层怎么决策”。这样调试的时候可以单独测试每一层出问题也容易定位。5.2 用状态机管理整车行为除了数据流之外整车行为建议用状态机来管理typedef enum { STATE_IDLE, // 待机 STATE_START, // 出发 STATE_TRACKING, // 循迹 STATE_SLOWDOWN, // 减速 STATE_STOP, // 停车 STATE_ABNORMAL // 异常 } CarState;每个状态对应一个独立的处理函数状态之间根据条件切换。比如检测到发车信号后从 IDLE 进入 START识别到停车区后进入 SLOWDOWN 再到 STOP。状态机的优势在于逻辑清晰不会因为某个条件漏判导致车在错误的时机做错误的动作。5.3 必须有调试通道智能车不是写完代码就能跑对的必须有数据回传手段。最简单的是通过串口把关键数据打印到上位机比如当前的转向量、目标速度、赛道中线位置、图像二值化效果等。更推荐的做法是加一块无线调试模块让车在赛道上跑的时候调试端能实时看到车的数据。这样不需要每次跑完停车再插线读日志效率会高很多。5.4 一个简化版控制循环模板下面是一个通用的控制循环骨架具体实现需要按你的主控平台、传感器类型和控制算法填充while (1) { // 1. 读取传感器数据 sensor_data_t sensor sensor_read(); // 2. 数据处理滤波、特征提取 track_info_t track process_sensor_data(sensor); // 3. 控制决策计算转向和速度 control_cmd_t cmd calculate_control(track); // 4. 执行输出 actuator_apply(cmd); // 5. 调试信息发送 debug_send(sensor, track, cmd); // 6. 控制周期延时 delay_ms(10); }这个循环里的每一步都可以单独测试。先用固定输入验证处理层输出是否正确再验证控制层在不同输入下是否给出合理的输出最后才整体跑车。6. 算法与调参方法论不要靠“感觉”调车调参是智能车备赛中最耗时、也最容易心态爆炸的环节。如果从头到尾都是“改一个数跑一圈看看效果”那大概率是在碰运气。更高效的做法是建立一套可记录、可对比、可回滚的调参流程。6.1 PID 调参的通用顺序无论是速度环还是转向环PID 调参的通用建议都是先 P 后 I 再 D每次只改一个参数。// 增量式 PID 简化示例具体参数需要按你的系统整定 float pid_update(float target, float current) { float error target - current; float output Kp * error Ki * integral Kd * (error - last_error); last_error error; integral error; return output; }先把积分项和微分项置零只调 Kp。增大 Kp 直到系统开始振荡然后退回 50% 到 70%得到一个基础响应。加入 Ki 消除稳态误差。注意积分饱和问题如果误差一直存在积分项会不断累积导致输出超限需要加积分限幅。最后加入 Kd 改善动态响应。微分项对噪声敏感如果传感器数据噪声大Kd 不宜过大。6.2 传感器数据处理不同组别的数据处理方法差异很大这里只强调几个共性问题摄像头图像要处理反光。 赛道表面材质不同在强光下会产生反光区域二值化阈值不能是固定的建议使用动态阈值。电磁信号要滤波。 原始电磁信号噪声较大建议先做滑动平均或低通滤波再做归一化处理。所有特征提取要留调试接口。 把二值化后的图像或滤波后的曲线通过上位机可视化比盯着数值更容易发现问题。6.3 调参记录模板每次调整参数之前强制自己先写一行记录。否则第二天你会完全不记得当前这组参数是怎么来的、为什么改的。示例如下时间2026-05-12 15:30 赛道标准环岛场地光线正常 电池电压8.0V 当前参数Kp1.2, Ki0.05, Kd0.3 修改内容Kp 从 1.0 提高到 1.2 测试结果弯道响应变快但直道出现轻微振荡 下一步Kp 回退到 1.1观察直道稳定性6.4 用“完赛率”代替“最快圈速”建议在做稳定性测试时不要只看最快一圈的成绩而是记录连续 10 圈的完赛率。哪怕慢了 0.2 秒只要 10 圈里有 9 圈完赛也远比 10 圈里只有 3 圈完赛的“快车”更接近比赛需求。比赛比的不是单圈极限而是那一趟发车能不能顺利完赛。7. 调试与测试方法把“偶然跑好”变成“稳定跑好”7.1 多场地测试智能车最怕的就是“只在实验室跑得稳”。实验室的赛道材质、光线条件、电磁环境都和比赛现场不同。建议条件允许的话提前到比赛场地或者相近环境进行适应性测试。重点观察不同光线条件下图像二值化是否稳定。不同赛道材质下轮胎抓地力差异。场地附近是否有强电磁干扰源。发车区域、停车区域的实际标志是否与规则描述一致。7.2 数据回放分析这里的核心思路是让车跑一圈同时把每个控制周期的输入、输出都记录下来。跑完之后不要只看“这圈跑得好不好”而是回放日志找到“是哪一段导致冲出赛道”的。# 假设串口调试数据实时保存到串口日志文件 # 跑完一圈后可以用脚本分析某个时刻的控制量是否异常 grep track_center /path/to/serial_log.txt | awk {print $2, $3} | sort -n | head -207.3 长时间稳定性测试赛场上赛车的极限状态可能只持续几分钟但电池从满电到低电的过程中车速和舵机响应会明显变化。建议在正式比赛前做一组“电池梯度测试”记录满电、中等电量、低电量三种状态下的车速和完赛率提前了解电量对性能的影响避免比赛时因为电池新旧问题导致整车状态不符。8. 技术报告与比赛材料别到最后一周才开始写技术报告是智能车竞赛的重要评分部分。很多队伍车跑得很好但报告写得敷衍导致整体成绩不理想。反过来一些技术方案完整的队伍即使车速不是最快也能拿到不错的整体分。8.1 技术报告推荐结构一个通用的智能车技术报告结构如下方案设计组别分析、总体方案选择、关键技术路线。硬件设计车模改造、主控选型、传感器布局、电源与驱动电路。软件设计软件架构、数据处理算法、控制策略、调试方法。实验与测试模拟环境测试、场地测试、参数调整过程、性能对比。问题与改进遇到的典型问题、原因分析、解决方案、后续优化方向。总结与展望。8.2 写报告的关键技巧从开赛第一天就建好文档目录每周补充内容。 不要等到最后一个月再补数据那时候图和日志早就找不到了。用数据说话。 测试数据、对比表格、调试曲线、完赛率统计这些远比文字描述有说服力。保留过程记录。 不成功的尝试、失败的参数调整也可以写进“问题与改进”部分反而显得报告真实、思考深入。注意原创与引用规范。 参考往年技术报告时可以学习结构和方法但不要直接复制内容。技术报告一旦涉及抄袭后果很严重。8.3 技术资料管理建议建议在团队内部建立一个共享资料库结构可以这样规划/智能车资料 /01_规则文档 /02_硬件设计 /原理图 /接线图 /数据手册 /03_软件代码 /主控工程 /上位机工具 /04_调试记录 /调参日志 /串口数据 /测试视频 /05_技术报告 /图片素材 /报告草稿9. 团队协作与经验传承最后一届队员最重要的工作“最后一届”这个身份意味着你不仅要完成自己的比赛还要把整个团队的经验留下来。技术能力是可以慢慢积累的但团队的隐性经验——哪些坑不用再踩、哪些方案已经验证过不可行——如果不用文档固化下来第二年新人加入一切又要从零开始。9.1 模块化分工建议按照硬件、软件、算法、文档四个方向分工每个方向设一个主负责人和一个备份。主负责人负责核心研发备份负责跟随学习避免出现“如果这个人退役了整个模块就瘫痪了”的情况。9.2 交接文档这样写交接文档不只是写一份代码说明而是写一份“从零开始”的入门指南。建议包含实验室环境说明设备位置、常用工具、芯片下载器怎么使用。硬件清单每个器件的型号、数量、购买渠道、注意事项。编译环境搭建开发工具版本、依赖库、编译步骤保证新人照着做能跑通。调试流程怎么下地测试、怎么看串口日志、怎么判断车是否健康。已知问题清单目前车存在的已知问题、可能的解决方向、不要再去碰的雷区。9.3 把“踩过的坑”按时序记录下来推荐的交接文档模板可以很简单## 智能车踩坑记录 ### 2026-03-15舵机供电不足导致高速抖动 - 现象车速拉到 3m/s 以上时转向响应明显变差 - 排查起初以为是 PID 参数问题后来发现是舵机供电电压被拉低 - 解决舵机独立供电加大电容问题消失 - 建议供电问题优先排查不要一开始就动算法参数这份文档越写越厚等到新队员接手时就能少走很多弯路。10. 常见问题与排查思路这里整理一份智能车备赛中最常见的问题排查表覆盖了从硬件到软件、从调试到赛场的典型故障。问题现象可能原因排查方式解决思路车跑直线明显跑偏舵机中位不准、左右轮距不一致、底盘倾斜拆下转向机构单独测试舵机中位输出电压重新校准舵机中位检查底盘对称性高速时转向抖动PID 的 P 过大、机械结构虚位、供电不足先固定机械再降 P 观察响应逐项排除先保机械再调算法高速直道突然冲出赛道速度规划过于激进、图像处理延迟过高回看日志检查冲出前的控制周期数据增加弯道前减速逻辑降低直道限速摄像头图像在强光下丢线反光导致二值化阈值失效查看二值化图像可视化窗口改用动态阈值调整摄像头曝光参数电磁信号波动大电源噪声、排线干扰、传感器距离赛道过近或过远查看滤波前后信号波形优化走线远离电机驱动线增大滤波强度电池电量下降后车速变化明显供电不足或控制器在低电压下性能衰减记录不同电量下的车速对比更换稳压方案或赛前统一使用满电电池代码编译通过但上电后车不动作硬件接线错误、初始化失败、看门狗复位检查串口日志和主控指示灯逐步初始化硬件打印状态信息定位卡住的位置技术报告数据不完整前期没有保存调试日志对照报告大纲检查缺失项从测试视频中截取数据或用实验室数据补做小规模实验11. 最后的话把经验写下来比车本身更有用26 年的夏天结束之后这辆车的使命就完成了。它会停在实验室的角落里或者被拆掉留给下一届做零件。真正能被留下来的是这套完整的备赛思路、调试方法、踩坑记录和交接文档。在我看来智能车竞赛最值得珍惜的不是比赛结果而是它强迫你在一整年里持续解决真实工程问题的过程。规则在变、技术栈在变、队友也在变但“对象清楚、分阶段推进、用数据说话、稳定优先于极限”这套方法论在任何工程领域都通用。如果你是第一次参赛的新队员建议从今天开始建两个文档一个是调参记录一个是踩坑记录。不要小看这两份文档等到赛前最后一个月它们会是你最宝贵的资产。如果你是和我一样的“最后一届”队员希望你在庆祝比赛结束之余也认真完成交接。把你验证过的经验留下来把走不通的路标出来这就是你能留给实验室最好的礼物。26 年的夏天我把车的钥匙留在了桌上。希望看到这篇文章的你也能在自己的赛季里跑得顺利停在终点线前的时候能安心地对自己说一句这最后一届值了。