21届智能车竞赛备赛到中期“我们的进度要完蛋了”这句话几乎是每个队伍群里都会出现的状态。白天调试车模跑不到两米晚上修改代码后转向直接反向机械结构拆了三次还没有固定距离提交校内验收和技术报告的截止时间又只剩几天。站在这个节点回头看进度失控并不是某一个人代码写得差而是整个团队的工程节奏出了问题。这篇文章想解决一个具体问题当智能车项目进度已经明显落后时应该按什么顺序补救。全文不会只讲“别慌、加油”这类空话而是围绕全国大学生智能车竞赛常见的技术链路给出任务拆解、硬件检查、软件调参、联调排错、赛前锁版五个阶段的可执行方案。哪怕你的队伍明天就要验收也可以按文中的清单快速判断最该优先做哪件事。1. 先判断进度失控的根源不要急着熬夜补代码1.1 进度焦虑背后通常是任务边界不清“进度要完蛋了”这句话的真实含义不是项目完全没有进展而是截止日期已经临近团队却说不清楚每个模块到底处于什么状态。机械装好了吗能跑多远转向是否稳定程序连续运行多久会复位这些问题如果只能回答“差不多了”“还在调”就说明任务边界还没有被拆出来。智能车项目是典型的软硬耦合任务机械结构影响车身姿态车身姿态影响传感器采集传感器数据影响控制逻辑控制逻辑又反过来要求机械结构稳定。任何一个环节都在给其它环节制造不确定性。四个模块纠缠在一起时团队每个人都会感觉自己很忙但每天结束又说不清到底完成了什么。进度的起点不是补代码而是先建立一张任务状态表。这张表不需要很复杂只需要列出模块、负责人、当前可验证状态、阻塞点四个字段。重点是“当前可验证状态”不能写形容词必须写能观察到的现象例如“舵机能在中值附近驱动”“编码器每 10ms 能读到稳定计数”“车模能以 0.5m/s 跑完 3 米直道”。有了这张表团队才知道真正缺哪个模块。很多队伍以为自己缺的是控制算法实际上缺的是电调校准或者只是电池电压已经掉到让单片机复位的程度。1.2 用瓶颈表把问题定位到具体环节当车模表现异常时不要凭感觉判断“是 PID 的问题”。更合理的做法是先按下面这张瓶颈表做一轮快速诊断把问题范围从“整个系统”缩小到“某一个环节”。现象可能瓶颈环节诊断方式车模跑不稳、左右摆机械结构、轮胎、编码器读取编码器脉冲波形检查轮轴虚位电机响应慢、起步顿挫电调校准、PWM 频率测 PWM 占空比和电机驱动输出直道突然加速传感器阈值、曝光参数查看上位机图像确认丢线和误判位置程序跑飞或复位电源电压、浮空引脚、低电量测启动瞬间电压查看复位标志寄存器转向方向反舵机中值、方向配置手动给定舵机占空比确认左右方向定义诊断阶段只做观察和测量不要急着改代码。比如舵机方向反了先确认硬件安装方向和占空比的对应关系再决定是改程序符号还是改舵机安装角度。盲目把控制量取反可能在当前车速下恰好能用换一个赛道元素又出问题。1.3 给团队一个统一的周状态机制进度补救阶段建议每周至少开两次短会每次不超过 30 分钟。开会只回答三个问题昨天完成了什么、今天准备做什么、有没有阻塞点。阻塞点必须写到可处理级别例如“摄像头排线接触不良等新排线”而不是“传感器这周一直有问题”。每次短会后更新状态表把“当前状态”写成可以验证的结果。状态表最忌讳的字段是“已开始”“在优化”“等调完”。这些词没有任何信息量。注意进度失控时最不需要的是更多热情而是更严格的验收标准。每项任务没有验收条件就不算完成。2. 把“完蛋感”拆成可执行任务从目标倒排工程2.1 先设定一个“能完赛”的最低目标全国大学生智能车竞赛的评分逻辑通常以稳定完赛为前提速度再快中途冲出赛道也没有成绩。进度落后的队伍第一目标不要定成“拿奖”而应该定成“稳定跑完一圈完成停车”。这个目标听起来保守却能帮助团队决定哪些功能要先做、哪些功能可以砍掉。最低目标可以这样定义车模能按照预设速度在简单直道上稳定行驶。能完成最基本的方向转向不冲出赛道。能检测起点线或停车区完成自动停车。程序在连续运行 10 分钟以上不异常复位。如果连这个目标都还没有达到就先不要碰复杂赛道元素也不要研究极限车速下的路径优化。先让系统有最基础的可控性再谈性能。2.2 按硬件、软件、机械、调试拆解任务清单一个典型的最小任务清单可以这样拆分机械结构固定底盘、舵机、电调和摄像头支架检查轮轴虚位整理线束。硬件电路确认供电方案检查电机驱动和编码器接线确认传感器与主控供电独立。软件控制实现 PWM 输出实现编码器读取实现电机闭环实现舵机转向控制。传感器链路确认摄像头上位机能输出图像确认电磁采样值稳定确定基础阈值。整车联调完成直道测试、弯道测试、起跑线检测、停车测试。每个任务必须指定负责人并给出验收条件。任务粒度控制在半天到一天能完成的程度。如果任务超过两天就要继续拆分。2.3 用倒排表控制截止时间假设比赛日为 D 日进度落后队伍的时间安排可以参考下面这张表时间节点目标必须完成的事项D-14整车能稳定跑完一圈机械冻结、供电稳定、代码闭环D-7能应付常见赛道元素完成弯道、坡道、起跑线等基础处理的验证D-3只修 bug不加新功能锁定代码和机械版本备份多份D-1适应比赛环境和赛道调整曝光、阈值、车速参数不修改核心逻辑倒排表的意义在于让团队知道最后三天应该留给“适应现场”而不是“开发新功能”。很多队伍在临近比赛时临时加入新代码结果调出了新的 bug把已经稳定的系统又搞崩了。2.4 每日例会只问三个问题昨天完成了什么验收结果是什么。今天准备完成什么谁来验收。有没有阻塞阻塞的最小负责人是谁。如果阻塞没有最小负责人就不能在例会上继续讨论而是会后单独跟踪。3. 硬件与机械稳定优先禁止边改边跑3.1 先冻结机械结构进度落后时机械改动往往是最大的坑。车模底盘、舵机安装角度、摄像头高度、传感器支架一旦确定就要尽可能冻结。不是因为不能再优化而是因为每次机械改动都会让之前的软件测试结果失效整个系统回到“不确定性”状态。建议做一张机械改动记录表记录内容包括改动日期、改动部件、改动原因、改动前后对比现象。哪怕只是换了一颗螺丝也要记录。没有记录下一次调参时就会分不清问题出在软件还是机械。如果发现某个机械问题反复出现例如轮胎跑偏、舵机虚位、摄像头支架松动先停下来解决机械问题再继续联调。临时用胶带固定或许能撑过一次测试但长期看会消耗更多时间。3.2 供电、地线和接触问题是隐形故障源智能车竞赛最常见的隐藏故障是供电设计不合理。电机启动瞬间电流很大如果单片机与电机共用电源或者超级电容容量不足电压跌落会让单片机复位。表现为车模一加油就重启跑着跑着程序回到初始化状态偶尔还伴随随机“死机”。学习阶段可以这样处理电机驱动使用独立的电池或稳压路径。单片机、传感器、舵机使用独立的稳压模块。所有模块之间必须可靠共地否则信号参考点不一致。电池电压低于某个阈值时程序通过 ADC 检测并主动减速停车。排查时用万用表测量电机启动瞬间的电压波形。如果看到电压跌到单片机工作阈值以下就基本可以确认是供电问题而不是程序逻辑问题。另外查看单片机复位标志寄存器能帮助判断复位来源是欠压复位、外部复位还是看门狗复位。3.3 传感器安装与标定要形成固定流程摄像头或电磁传感器的安装位置直接影响数据质量而这些参数每次调完都可能被不小心改动。建议把传感器的安装位置和标定参数写入配置头文件例如摄像头安装高度、俯仰角、曝光时间、图像阈值电磁传感器的安装高度、间距、基准值。标定流程要固定让车模分别停在白色赛道、黑色引导线、背景区域。记录三种区域下传感器的原始值。根据原始值取中间阈值或计算动态阈值策略。把阈值写入代码同时记录在技术报告。不要在每次烧录时手动改阈值。参数一旦分散在两三个文件里联调时很容易改错位置。3.4 硬件排错要有固定手段硬件问题排查可以按下面的顺序来接触不良通电后按压关键线束观察现象是否变化。编码器计数跳变检查 AB 相接线是否正确是否缺少上拉电阻。电调响应异常重新校准油门行程确认 PWM 频率匹配。电池电量不足记录电压阈值对电池状态做保护。电机方向不一致单独测试每个电机确认接线和转向定义。在比赛现场硬件问题如果不能在几分钟内定位就直接使用备用件替换。这也是为什么赛前需要准备备用电调、舵机、编码器和下载器的原因。4. 软件策略先让车能跑再让车跑得快4.1 最小系统控制链路在接入传感器之前先让车模具备最基础的控制能力电机能转、舵机能转、编码器能读数。这个最小系统不需要任何智能算法只需要以下几个模块PWM 初始化。电机方向和占空比控制。舵机中值和左右占空比控制。编码器读取。定时的控制周期。下面是一个精简的控制结构示例用于说明思路实际项目需要根据主控型号和所用库调整typedef struct { uint16_t steer_mid; // 舵机中值占空比 uint16_t steer_left; // 左转极限 uint16_t steer_right; // 右转极限 } SteerConfig; typedef struct { int16_t target_speed; // 目标速度单位由编码器换算决定 int16_t current_speed; // 当前速度 int16_t steer_output; // 舵机输出偏移 } VehicleState; void control_loop(VehicleState *state) { state-current_speed read_encoder_speed(); // 速度闭环和转向闭环在这里计算 set_motor_pwm(state-target_speed); set_steer_pwm(state-steer_output); }在实际工程中控制周期要固定。常见做法是使用定时器中断每 10ms 或 5ms 执行一次控制逻辑。不要在一个循环里用while(1)加粗延时做控制时间不准确会导致 PID 输出忽大忽小。4.2 PID 调参顺序先内环后外环先比例后积分微分PID 是智能车控制的基础但大多数队伍的问题不是“不会写 PID”而是“跳过了内环调参直接调整车”。正确的调参顺序是先让编码器速度闭环稳定也就是内环。再调转向环或路径跟随环也就是外环。外环不稳定时先减小外环 P 值不要先加 D 值。每个环路的参数调整后都要记录现象。一个常见的增量式 PID 实现如下typedef struct { float kp; float ki; float kd; float integral; float last_error; float output_max; } PidController; void pid_init(PidController *pid, float kp, float ki, float kd, float output_max) { pid-kp kp; pid-ki ki; pid-kd kd; pid-integral 0.0f; pid-last_error 0.0f; pid-output_max output_max; } float pid_calc(PidController *pid, float target, float current) { float error target - current; pid-integral error; float derivative error - pid-last_error; pid-last_error error; float output pid-kp * error pid-ki * pid-integral pid-kd * derivative; if (output pid-output_max) { output pid-output_max; } else if (output -pid-output_max) { output -pid-output_max; } return output; }调参实践中P 值从小往大加直到系统出现轻微震荡再引入 I 值消除稳态误差最后用 D 值抑制超调。每次只改一个参数改完后跑同一段赛道对比现象。注意不要在没有速度闭环的情况下直接调路径跟踪。路径跟踪输出的是目标转向目标转向作用于车辆姿态而车辆姿态又依赖稳定的速度。没有内环外环就是空转。4.3 传感器策略先做降级方案传感器处理效果不好时先不要上复杂算法。图像方案可以先只提取一行图像中的黑线位置算出偏差电磁方案可以先只用两路电感做差得出左右偏量。一个最简化的图像偏差计算示例float calc_line_deviation(uint16_t *line_pos, uint8_t row) { // 假设 line_pos[row] 是当前行黑线的横坐标 // IMAGE_CENTER_X 是图像中心横坐标 return (float)line_pos[row] - IMAGE_CENTER_X; }这里的偏差值就是接下来转向 PID 的输入。先让这一条计算链路跑通再考虑多行拟合、断线补线、弯道前瞻等增强逻辑。同时代码里应该预留一个“保守模式”当传感器数据异常、丢线、超时未更新时让车模减速并沿用上一帧的方向。这个模式不需要多聪明只需要能避免车模直接冲出赛道。4.4 日志和上位机调参联调阶段最怕的是看不到系统内部状态。建议通过串口输出关键信息例如循环周期、目标速度、当前速度、偏差值、PID 输出、舵机占空比。printf(cycle%u speed%d target%d steer%d error%d\r\n, (unsigned int)tick, motor_speed, target_speed, steer_output, error);输出频率不需要太高10ms 或 20ms 一次即可。使用虚拟示波器软件查看波形能直观看到速度超调、震荡和响应延迟。实际工程中使用串口重定向或逐飞库提供的sci_printf相关函数具体函数名以队伍使用的库为准。日志开关要保留比赛阶段可以关闭部分输出避免串口占用过多 CPU 时间影响控制周期。5. 联调排错从现象倒推根因不靠猜5.1 联调时的排查顺序车模表现异常时推荐按下表顺序从源头往执行机构排查现象检查顺序电机不转电池电压 - 电源开关 - PWM 占空比 - 使能引脚 - 电调校准 - 接线电机抖动PWM 频率 - 电调校准 - 供电电流 - 接线接触转向不灵舵机供电 - 舵机中值 - 占空比范围 - 舵机臂安装速度读数为 0编码器接线 - 上拉电阻 - 定时器配置 - 清零时机跑飞复位供电电压 - 复位标志 - 看门狗 - 浮空引脚 - 数组越界先确认输入再判断输出。很多队伍在程序里反复调试最后发现是编码器 AB 相接反导致读数始终为 0速度环自然无法工作。5.2 典型故障与处理转向反向现象车模进入弯道后朝反方向打角。可能原因是舵机安装方向与程序定义的左右方向不一致。处理方式先手动给定舵机固定占空比确认左转和右转对应哪个占空比再决定是修改程序方向符号还是调整舵机安装角度。启动瞬间复位现象一加油门主控重启。优先怀疑供电跌落。检查电机驱动是否与主控共电源测量启动瞬间电压确认电池健康状态。如果电压正常再查复位标志寄存器和看门狗配置。图像丢行或花屏现象上位机看到图像不完整、画面撕裂或完全无信号。优先检查摄像头排线接触、DMA 缓冲区配置、图像大小与存储空间是否匹配、曝光时间是否过长。换一根排线往往能快速定位接触问题。起跑线误检测现象车模在正常赛道段触发停车。检查阈值是否过窄、曝光是否让黑白边界不清楚、检测逻辑是否把普通横线当成了起跑线。可以在检测区域做二次确认例如要求连续 N 帧都满足条件才触发。5.3 用调试记录压缩排错时间每支队伍都应该有一份调试图哪怕只是写在便签上也要记录四列内容时间、修改项、现象、结论。例如时间修改项现象结论10-12 14:00更换摄像头曝光值直道抖动减轻曝光需要与控制周期匹配10-12 15:00编码器接线改为 AB 反接速度读数反向确认接线定义后修正方向10-12 16:00加大速度环 P 值起步震荡退回上一组参数改用 I 值消除稳态误差没有记录队伍就会反复调同一个参数。尤其是多人同时调试时前一个人刚改完 P 值后一个人不知道又改回原值半天时间就这样消耗掉了。6. 赛前一周和比赛日不要引入新变化6.1 赛前三天锁定代码和机械版本到了赛前三天核心目标已经不再是把算法调得更快而是保住当前已经稳定的状态。此时只允许修 bug不允许加新功能不允许更换核心传感器不允许改动机械结构。建议做以下动作将所有代码备份到两个以上的位置。给可运行版本打上标签例如v2025_final_circle_a。记录当前所有关键参数速度、PID、曝光、阈值、舵机中值。确认下载器和烧录环境能在比赛电脑上正常工作。如果赛前临时出现无法解决的新问题宁可放弃新功能也要保证旧版本能稳定运行。6.2 比赛日物品与检查清单比赛现场最容易遗漏的不是代码而是硬件配件和工具。建议提前一天装好材料包车模本体电池至少两块且充满电。充电器、备用电池。备用电调、舵机、编码器、排线。下载器、USB 线、电脑、充电宝。常用工具螺丝刀、扎带、胶带、剪刀、烙铁。上位机软件和驱动安装包提前在比赛电脑上验证。到现场后按顺序检查机械螺丝是否松动、电池电压是否正常、接收启动信号是否正常、转向是否左右一致、轮胎是否磨损影响抓地力。这些检查看似基础却是很多队伍在比赛现场翻车的直接原因。6.3 现场突发情况的处理原则现场如果出现车模异常先确认是环境因素还是程序因素。处理原则如下先看数据和现象再改代码。优先使用已验证的配置不要临时换新算法。修改前备份当前代码防止改坏后无法回退。每次只改一个参数改完立刻跑赛道验证。如果连续两次修改效果更差立即回退到上一个稳定版本。比赛日的目标不是“做到最好”而是“把准备做出来的水平稳定发挥出来”。任何在赛前 24 小时才引入的新改动都可能让整支队伍之前的努力归零。7. 最该记住的三条经验7.1 进度问题的本质是工程问题不是代码问题“我们的进度要完蛋了”听起来像一句抱怨但它在工程上描述的是一个真实状态任务没有拆解、依赖没有理顺、验收标准没有建立。代码写得再熟练如果机械结构没有冻结供电不稳定传感器标定不对整个系统依然无法收敛。当进度失控时第一反应不是增加工作时间而是减少不确定性。把每个模块的状态写到可验证把所有阻塞点分配到人把最后几天留给稳定运行而不是新功能开发。团队一旦从“在忙”切换到“在收敛”进度恢复的速度会快很多。7.2 没有记录就没有调试记录是整个备赛周期最便宜也是最容易忽略的工具。机械改动要记录参数调整要记录故障排查要记录甚至一次测试失败的现场照片也要保存。记录不只是留给技术报告用的它真正的作用是让下一轮调试不用重新走过以前踩过的坑。建议从项目一开始就建立三个文档硬件接线表、参数记录表、故障排查表。进度再紧这三个文档也不能停更。它们不要求长期写而是每次调试结束时花三分钟补上。7.3 给下一届队伍的建议如果把这篇文章压缩成一句话那就是先保证系统能稳定跑完再考虑跑得快先拆解任务边界再讨论辛苦程度先记录每一次改动再凭记忆继续调参。对准备参加下一届比赛的新队伍这里还有一份更长期的学习清单第一周学会主控开发环境、下载和点灯熟悉 GPIO、PWM、定时器。第二周让电机和舵机转起来建立最小控制链路。第三周接入编码器完成速度闭环理解 PID 的意义。第四周接入传感器跑通最简单的偏差计算。第五周整车联调完成第一圈完整赛道。之后逐步加入前瞻、补线、坡道检测、起跑线识别等进阶功能每加一个功能都要单独验证。7.4 常见坑速查坑现象处理建议机械边改边跑无法判断问题来源冻结机械改动记录原因供电公用加油门复位电机独立驱动主控独立稳压编码器接反速度为 0 或反向检查 AB 相定义和上拉电阻跳过分段调参转向震荡先内环后外环每次只改一个参数赛前加新功能稳定版本崩溃赛前只修 bug回退到已锁定版本智能车项目最宝贵的调试资源不是时间而是确定性。每减少一个不确定因素进度就会前进一步。如果今晚你所在的队伍还在为进度焦虑可以先放下代码花半小时把状态表填好然后选出唯一一个“明天必须跑通的最小闭环”。把这个最小闭环做完进度就不会一直“完蛋下去”。