智能车备赛进度落后？拆解卡点、稳完赛优先，再提速

“进度要完蛋了”这句话几乎每年智能车竞赛备赛期都能听到。21届智能车备赛的焦虑往往不是车队不努力而是任务边界不清、调试顺序混乱、临场状态不可控。先说结论进度崩不崩取决于你还能不能把“没做”和“没调”拆清楚。如果只盯着倒计时叹气车不会自己变快如果能把剩余工作拆成可验证的小块很多“要完蛋”其实还来得及救。这篇文章适合正在备赛智能车、尤其是进度已经落后的队伍。也适合刚接手车队、还没搞清楚先做什么的队长和技术负责人。下面按照实际备赛顺序拆一遍先定位进度卡点再补环境接着分阶段推进最后处理心态和团队协作。我不写空洞的加油只写能落地执行的检查方法和排错顺序。1. 先看清21届智能车进度到底卡在哪进度落后的时候最忌讳的是所有人围在一起看着车模说“哎呀不行了”。这种情绪没有任何信息量。你要做的是把“进度”这个词拆成可以检查的状态然后逐项确认。1.1 智能车项目不是“只剩调车”那么简单很多队伍觉得车已经能跑了剩下的就是调参数所以整体进度应该很快。这个判断最容易让计划崩盘。一台智能车能否稳定完赛涉及硬件接线、机械结构、电源供电、传感器数据、控制算法、代码逻辑和现场环境适应七个层面。你看到的是“车跑偏了”但真实原因可能是轮胎左右磨损不一致。电池电压下降导致电机输出不足。摄像头安装角度松动。编码器线接触不良速度反馈值跳变。舵机中值偏移。PID 参数方向反了。程序里某个变量因为长时间运行溢出。如果只把问题归类为“调车”就会陷入反复改参数、永远调不完的死循环。正确做法是每次测试只改一个变量并且记录测试前后差异。没有记录就等于没有测试。1.2 区分硬件、软件、机械、排期四种进度滞后进度落后不是一种原因至少要分四种情况。第一种是硬件进度滞后。比如主控板还没焊好、电机驱动没有装、传感器接口定义不明确。这类问题最要命因为下游所有软件调试都依赖硬件。遇到这种卡点第一天就应该把电路连接图打出来贴到桌上每个人看板子先看接口再谈代码。第二种是软件进度滞后。表现为硬件能跑但驱动代码、控制逻辑、图像处理或串口通信没写完。这类问题可以通过抓日志来判断。只要串口能输出调试信息问题通常都能定位。第三种是机械进度滞后。车模装配不对、底盘不平、轮胎打滑、舵机臂虚位、重心太高。机械问题很难靠调程序解决。你调三天 PID都不如把底盘重新装一遍来得快。第四种是排期进度滞后。任务没有优先级今天调摄像头明天调电机后天改机械结果样样都半成品。这种进度落后最隐蔽因为它看起来大家都在忙。建议用一张表格记录当前状态模块是否接线完成是否基本可用是否稳定负责人下次验证时间主控最小系统是是是A每天开机测一次电机驱动否否否B待焊线编码器是是不稳定C今天重焊接头摄像头图像是是是A连续跑 50 分钟看卡顿转向舵机是是是B测试左右极限角度先把这张表填满再判断“要完蛋”到底是从哪里开始完蛋的。很多时候队伍只有一台车、一个主控板、一位主力队员在写代码其他人没有明确任务这才真正完蛋。2. 进度崩掉之前先把环境、工具链和物料清单理清如果进度已经落后最不能省的就是环境准备。不要觉得这些是前期工作现在补还来得及。很多“莫名奇妙的问题”到最后都指向工具链不一致、下载线接触不良、代码没有一个备份。2.1 车模、主控、传感器、电源等物料清单智能车项目涉及的物料不少建议按功能模块准备。不要等到比赛前一周才发现少了一根排线或者某颗螺丝规格不对。常见的物料分组车模底盘与机械件轮胎、轮毂、电机、舵机、底盘支架、螺丝套装、扎带、铜柱。主控与驱动主控单片机最小系统板、电机驱动模块、舵机供电模块、电源模块、稳压模块。传感器摄像头、电磁传感器、编码器、陀螺仪、加速度计、超声波或激光视赛项要求。线材与接口杜邦线、排针排母、电源线、USB转串口、下载器、热缩管、焊锡、电烙铁。调试工具万用表、示波器可选、逻辑分析仪可选、串口调试助手、备用电池。这里有一个容易忽略的点物料不只是“有没有”还要看“能不能用”。建议每周检查一次电池健康度、排线插头是否松动、焊点是否氧化。备赛后期很多问题都是接触不良造成的而不是算法不行。2.2 开发环境与编译下载链路软件环境同样要提前固定下来。最常见的错误是队里三个人三台电脑三个不同版本的 IDE结果代码在 A 电脑能编译在 B 电脑报错在 C 电脑下载后运行结果不一样。建议统一以下内容IDE 或编辑器版本。编译器版本。芯片包/固件库版本。下载调试器型号和接线方式。串口调试工具的波特率、换行符设置。如果条件允许把编译好的固件留存一个固定目录命名为“日期_版本_说明”。比如20250520_v3_增加弯道降速。现场调试时直接烧录最新验证过的固件不要临时改代码。2.3 版本管理与代码备份很多车队不用 Git理由是“代码又不复杂”。但这个习惯在备赛后期会带来灾难。你改了十行代码车从能跑变成不能跑你想回退却不知道原来那一版叫什么。我建议至少做到每天测试前保存一份当前代码。大改动前单独复制一份。每次调参后记录关键参数不只在代码里改还要写进实验记录。如果团队多人开发用 Git 管理至少学会commit和branch。一个简单的做法是在工程目录里建一个history文件夹每天按日期打包保存。虽然不优雅但比丢代码强。注意如果车队现在还没有版本管理不要花大半天去学 Git 全流程。先建立“每日快照”习惯五分钟就能完成。3. 从“能开机”到“能跑完一圈”分阶段推进计划进度落后的时候最需要的是分阶段推进。不要一上来就调 PID不要一上来就追求极速过弯。按下面的顺序每一步都有明确的完成标志。3.1 第一阶段点亮 LED、读取传感器、驱动电机第一阶段的目标是“打通链路”而不是“跑得好”。具体来说主控板能上电程序能烧录。LED 能按预期点亮证明基本 IO 正常。按键、拨码开关、串口能输入输出。编码器能读出轮速。摄像头能输出图像或电磁传感器能读到 ADC 数值。电机能转舵机能转。这一阶段如果还没完成进度确实比较危险。但它通常只需要两三天完整时间。只要硬件不是大面积损坏别慌一个个模块验证就行。验证方法很简单写一个最小程序只测一个功能。比如只让左轮以 30% 占空比转 3 秒然后停止。如果连这个都不正常先检查供电、接线、驱动使能引脚而不是直接写复杂控制代码。3.2 第二阶段开环跑直线和转弯开环的意思是不给速度反馈直接给定 PWM 让电机转动。这阶段能验证机械装配、驱动能力和转向响应。先让车跑直线。注意如果左右电机占空比相同车却不走直线不一定是代码问题可能是左右轮胎气压不一样。电机性能有差异。电池供电不足导致两侧驱动压降不同。底盘安装不平。开环跑直线时建议把速度设定在低速比如占空比从 20% 开始逐步增加。记录跑 1 米需要的时间和偏移量。转弯验证时先给固定转向 PWM观察转弯半径。不要一上来就叠加速度控制。如果开环都转不好闭环只会更乱。3.3 第三阶段闭环循迹与速度控制闭环控制可以理解为“让车根据传感器反馈自动调整执行器”。常见的闭环包括速度闭环编码器测量轮速控制电机输出。转向闭环摄像头或电磁传感器计算偏差控制舵机转角。综合控制根据赛道元素直道、弯道、十字、坡道切换目标速度和转向策略。这一阶段最容易出现的现象是“震荡”。车在赛道上来回摆头或者速度忽快忽慢。遇到这种情况不要急着把 PID 三个参数都改了。先记住一个原则先调 P再调 D最后处理 I。如果再细分PID 调参方法分为两步先把 I 和 D 置零只保留 P。从小到大增加 P观察系统响应。当车开始出现小幅度震荡时适当增加 D 来抑制。如果存在稳态误差再加入少量 I。这里给不出万能参数因为不同车模、不同赛道、不同电压下参数范围都不一样。但判断标准是通用的现象可能原因优先调整项转向太迟钝入弯晚P 过小增大 P左右快速摆头P 过大或 D 过小减小 P 或增大 D直道速度波动速度环参数不当检查目标速度和编码器信号出弯后跑向外侧转向响应慢增大转向 P 或提前判断弯道车越跑越慢电池电压下降或 I 饱和检查供电和积分限幅3.4 第四阶段综合调参与比赛工况当车能稳定跑完一圈后才进入综合调参阶段。这个阶段的目标不是“再快一点”而是“在各种条件下都能完赛”。需要测试的工况至少包括满电状态和低电状态。有光照和无光照。轮胎温度高和低。连续跑 10 圈以上。停车重启后能否继续跑。摔车、碰撞后是否需要重新标定。不要只测一次。很多时候车第一次跑得好第二次就出问题是因为某个状态没有复位或者某个变量累计溢出。综合调参时要记录环境、电压、圈数、成功与否。如果时间确实不够优先保证“稳定完赛”。先让车以较低速度稳定跑完一圈再一点点提速。哪怕一圈很慢也比比赛时冲出赛道强。4. 进度要完蛋时哪些坑最容易让人误判进度越紧张越容易病急乱投医。下面这些坑我见过很多次每一个都会让队伍多浪费一两天时间。4.1 硬件接触不良被当成软件 bug最典型的情况车第一次跑正常第二次一上电就不动了。于是开始检查代码、重烧程序、调参数。结果弄了半下午发现是电池接头松了或者杜邦线掉了。排查时先把硬件固定检查一遍。我一般会这样做每次上电前用万用表量主控电压、传感器电压、电机驱动电压然后逐个晃动关键接线看串口输出有没有跳变。如果晃动时数据异常直接换线。不要用胶布缠一下继续用现场会复发。4.2 参数看不懂就乱调反而越调越差调参不是凭感觉。很多队伍看到车跑偏直接把某个 PID 参数乘以二结果车从轻微偏变成剧烈震荡。正确做法是每次只改一个参数。每次改完后跑相同的测试路段。记录改前、改后的现象。如果两次都是同样的偏移先考虑机械和传感器问题再考虑参数。调参最忌“连环调”。把 P、I、D、目标速度、转向限幅一起改出了问题根本不知道是哪一项造成的。进度越紧越要稳。4.3 只测新功能不回归验证旧功能备赛后期每改一次代码都应该先跑一遍基础功能。哪怕你今天只改了一个弯道检测逻辑也要重新确认直道识别没有坏。回归测试不一定很复杂。准备一条固定的测试赛道记录跑一圈的时间、是否冲出赛道、有没有异常停车。只要测试时间和异常次数变化立刻判断是新增改动还是环境因素。如果等到比赛当天才发现原来的直道识别被改坏了那才是真正的“进度完蛋”。4.4 依赖资料但资料过时网上关于智能车竞赛的资料很多但很多资料是几年以前的老版本。芯片型号、开发环境、库函数、赛规都可能变了。使用资料时注意三点核对芯片型号和固件库版本。先跑通官方示例再移植别人代码。资料里的参数要当成参考不要直接照搬。如果按照某篇博客改了代码反而报错先找原版示例做对比不要全盘否定自己的工程。5. 把剩余时间拆成“冲刺前、比赛前一周、赛场前”三阶段进度紧张时不能每天只想着“到底能不能完成”。把剩余时间切成阶段每个阶段盯住不同的目标。5.1 冲刺前先冻结机械结构再调软件离提交作品或比赛还有 1 到 2 周时第一件事是冻结机械结构。也就是说不要再改底盘打孔位置、换舵机安装方式、换大轮胎。原因很简单机械结构一变所有传感器标定、PID 参数、重心分配全得重来。没有足够时间反复验证。冲刺前的主要任务把车体紧固件全部检查一遍该上胶上胶该换螺丝换螺丝。固定电池位置防止高速运动时电池移位。把传感器安装在稳定支架上不要用容易形变的双面胶或热熔胶堆。清点备件备用电机、舵机、主控板、排线、螺丝、电池。5.2 比赛前一周按比赛流程做全流程测试很多人以为比赛就是“发车、跑圈、结束”。实际上赛前还有检录、摆放、调试、等待等环节。全流程测试要模拟这些环节。测试内容包括从关机状态到发车的准备时间。充电、换电池、插线的操作顺序。上电后是否需要重新校准陀螺仪或摄像头。连续发车多次看是否每次都能正常起步。万一发车失败重启后能否恢复。这一周的目标是减少意外。要在测试中故意制造一些“故障场景”比如断电重启、手动推一下车、在赛道上洒一点水看看程序会不会崩溃。5.3 赛场前准备备份零件、电池和调试脚本真正的赛场环境和你平时的实验室完全不同。光线、场地摩擦力、电磁干扰都可能不同。出发前准备一个“比赛包”一块已经调好的主控板。一块备用主控板烧录相同固件。两套传感器万一现场故障能快速换。至少三组充满电的电池并确认放电特性一致。常用工具电烙铁、万用表、螺丝刀、扎带、胶带、剪线钳。同时准备一个“现场调试脚本”不一定写成文档但至少心里有数上电后先看串口输出是否正常。检查电池电压和传感器数据是否在合理范围。低速跑一小段确认转向方向和速度方向正确。再进入正常比赛模式。如果在现场遇到问题不要马上改参数。先记录现象再判断是环境因素还是程序问题。现场条件不充分大改代码风险很高。6. 进度焦虑的正常与应对心态和团队协作最后聊一点情绪和团队管理。这个东西看起来和技术无关但进度崩掉的项目多半是团队协作出了问题。6.1 焦虑是正常信号不是能力问题备赛到后期进度落后是常态。几乎每个参赛队伍都会经历“这周完全没进展”的阶段。焦虑本身不可怕它说明你们还在意结果。但焦虑要转化为行动不要变成互相指责。如果队长说“进度要完蛋了”应该立刻问三个问题现在哪项任务是最大瓶颈瓶颈卡在什么具体环节今天能做什么让瓶颈有一点松动只要这三个问题能回答焦虑就有出口。6.2 每天确立一个可验证的小目标大目标太遥远比如“下周让车跑完一圈”。这种目标不适合每天执行。更适合的是“今天让摄像头图像在串口调试助手连续显示 30 分钟不卡顿”。小目标满足几个条件当天能完成。有明确验证方式。做完后能向大家汇报结果。即使没完成也能说出卡在哪一步。每天结束前把结果记录到群聊或文档里。不用写长篇总结写三行就行今天做了什么。结果怎样。明天做什么。这个习惯花不了十分钟但能极大减少“感觉在忙实际没推进”的状态。6.3 团队对接用表格记录问题而不是口头记忆备赛后期各种问题会同时出现。如果只用嘴说信息会丢失。建议在实验室白板上画一个简易表格或者用在线文档维护几个清单问题清单现象、优先级、负责人、下次验证时间。物料清单缺什么、什么时候到、谁负责催。参数记录改了什么、为什么改、改前改后现象。任务清单今天谁负责什么、预计完成时间。这里特别强调参数记录。很多队伍到比赛前一天发现车突然跑不好最后查出来是有人昨天改了某个阈值。如果记录清楚马上能回退没有记录只能从头再查。写在最后的一点建议如果现在你们的进度已经非常紧张不要花时间去懊恼前面丢了多少时间。先把“进度要完蛋”具象化列出没完成的任务、当前卡点、剩余时间然后按“稳定完赛”优先排序。我在实际备赛中最大的感受是真正让一个车队完蛋的从来不是能力不足而是任务没有优先级、问题没有记录、改动没有验证。21届智能车压力大是正常的。但只要你还能让车以安全速度跑完一圈就还有机会。先把这一圈跑稳再谈速度和名次。后面的路一步一步走反而更快。