第一次在实验室里看到学长调好的智能车从坡道冲下来又稳稳切进弯道我脑子里只剩下四个字飞檐走壁。那会儿学校第一次组队参加全国大学生智能车竞赛我们几个专科生连正经的开发板都没碰过却要在几个月内做出一辆能上赛道的车。后来真正跑完整个备赛周期我才意识到这场比赛真正稀缺的不是天赋而是把规则、硬件、算法和现场应变串成一条线的能力。这篇文章没有“大佬一挑三”的爽文剧情我只想复盘一支普通专科队伍第一次参赛时最容易踩的坑以及我们后来沉淀下来的一套最小可用的工作流。1. 为什么第一次参赛你最该先啃那份规则手册很多新队伍第一次拿到赛题第一反应是“赶紧买传感器”“赶紧跑代码”。实际上最应该先做的是把规则手册当成第一份技术文档来读。智能车竞赛和平时自己做小玩具最大的区别是它有一整套明确的边界。赛道元素、车模规格、传感器限制、电压限制、调试流程、现场规则甚至连发车区的朝向都写在里面。你不读规则就动手后面大概率要返工。1.1 先把“飞檐走壁”翻译成能拆解的任务“飞檐走壁”听起来很玄但落到规则里其实就是一组需要实现的赛道元素组合坡道、颠簸路面、连续弯道、十字交叉、窄道。比赛比的是谁能在这些元素里跑得又快又稳而不是谁的车长得更帅。所以我们第一次读规则时应该把形容词翻译成任务清单。任务清单可以这样拆循迹能力让车沿着赛道中线行驶不能压线、出界。通过能力遇到坡道不卡、不飞遇到颠簸不跑偏。稳定能力连续跑十圈圈速波动在可接受范围内。速度能力在稳定基础上逐步提高目标速度。每一类任务再往下拆就会变成具体的技术指标。比如“通过坡道”可能需要坡度、坡长、坡顶平台宽度、车速上限、电机扭矩、电池压降。这些数据从哪里来还是从规则手册和往届技术报告里找。第一次参赛不要凭感觉定参数要多看前人的经验总结。1.2 从规则手册里找出“边界”而不是只看题目规则手册里最有价值的部分往往不是“要做什么”而是“不能做什么”。它就像游戏里的红线和隐藏规则决定了你的选型和方案是否合法。以常见情况为例规则可能限制车模的长宽高、车轮数量、电池电压、传感器类型和数量甚至限制主控芯片的型号范围。如果一开始就选了自己最熟悉的板子等到现场检录才发现不符合要求再换主控等于重写底层代码。这个风险在第一次参赛时尤其致命。所以建议准备一张“规则边界表”凡是手册里出现“限制”“不得”“应使用”“必须”的地方全部摘出来标成硬性约束。再对照自己的方案看有没有冲突。规则答疑帖、官方群内的回复、往届参赛队的提问记录也要定期翻一遍。第一次参赛最大的信息差就在这里。1.3 一份由规则倒推的时间表把规则理清楚之后就可以倒推备赛时间表了。第一次参赛建议至少留出 10 到 12 周不要试图在一个月内冲刺。一个常见的零基础时间分配是第 1 周读规则拆任务确定整体方案。第 2 周准备硬件搭建最小系统让车能通电、能下载程序。第 3 到 4 周跑通开环让车可以按固定占空比前进、转向。第 5 到 8 周接入传感器实现巡线闭环逐个完成赛道元素。第 9 到 10 周整车联调记录不同参数下的表现做稳定性测试。第 11 周备份全套参数准备现场降级方案。第 12 周模拟现场环境练发车流程做应急演练。这里面的节奏核心是先跑通再稳定最后才是提速。不要一开始就把目标圈速定得太激进否则后期会因为稳定性不足一直回退。2. 硬件选型别只看性能要看你能不能调试第一次参赛的硬件选择直接决定了后面调试的舒适度。很多新手喜欢选性能最强的传感器、算力最高的主控、功率最大的电机结果整套系统上电后光排查干扰就花掉了大半个月。硬件不是越强越好而是越容易调试越好。2.1 先用“最小系统”把链路跑通所谓最小系统就是一通电就能看到效果的最简配置。对智能车来说至少包括电池、电源模块、主控板、电机驱动、两个电机、一个转向舵机如果车模是转向结构以及一个传感器。第一次做的时候不要一上来就同时接摄像头、陀螺仪、蓝牙、显示屏、遥控器。先让车在低速下能前进、能转弯、能停确认主控、驱动、电池三个核心模块没有硬伤。这个过程可能只需要一两天但能帮你排除一大堆新手问题。具体流程可以这样做先把车架空拆掉轮胎让电机空转。写一个最基础的 PWM 输出程序给电机不同的占空比听声音是否正常。再写一个舵机或差速转向程序确认转向方向正确。最后把车放回地面低速跑一小段确认能走直线、能转弯。这期间要重点检查电源。很多人第一次遇到的问题是电机一转主控就重启或者摄像头图像出现水波纹。90% 是因为电机大电流拉低了电源电压给主控和传感器造成了干扰。解决思路是主控和传感器用独立的稳压模块电机驱动单独供电共地但不共电源线。2.2 传感器、主控、电机驱动按什么顺序选硬件的选型顺序应该从“最难复用的部件”开始。第一个锁定的通常是传感器因为它决定你的代码复杂度和调试工作量。摄像头要求光照稳、视野合适、图像传输延迟低电磁传感器要求 ADC 采样稳定、抗干扰好。第一次参赛建议选择社区资料最多、教程最完整的传感器而不是参数最好的。第二个是主控。主控的选择取决于传感器接口和所需算力。使用摄像头时至少需要一颗能跑图像处理的中等性能 MCU使用电磁传感器时普通 MCU 就够。原则是用自己最熟悉的开发环境因为备赛时间很紧不要把时间浪费在熟悉新 IDE 上。第三个是电机驱动。根据自己的车模电机功率和电池电压选至少保留 1.5 倍余量的驱动模块。宁可驱动发热慢一点也不要频繁过热保护。最后是电源和线束。很多人忽略线束其实线束松动会导致现场偶发跑飞排查难度远高于代码。2.3 哪些钱不能省哪些东西可以省第一次参赛预算一般有限。我的建议是以下东西不能省可靠的双路 DC-DC 稳压模块至少留一路给主控和传感器。调试器或仿真器能在线断点调试。串口转 USB 模块方便看日志。备用电机、备用舵机、备用驱动。稳压模块的散热片或小风扇。可以省的是过度性能的主控比如 1GHz 以上的开发板。铝合金 CNC 底盘普通亚克力车架完全够用。无线遥控和上位机界面对第一次参赛不是必需品。外观装饰件比赛不评分。注意不要因为省钱而买杂牌电池。电池是整个系统的能量来源劣质电池的压降、容量衰减、安全问题都会在赛场上集中爆发这个钱不能省。3. 让车“飞檐走壁”的控制逻辑从会跑到跑稳“飞檐走壁”不是真的让车飞起来而是让车在高速、坡道、连续弯道下依然稳得像粘在地上。这就需要控制逻辑从“能走”升级为“能稳定走”核心是闭环控制。3.1 开环到闭环先把“跑直线”做扎实很多新手一上来就写闭环结果车越调越乱。正确路径是先做开环再做闭环。开环阶段先不依赖传感器直接给一个固定 PWM 值看车能不能直线走一小段。你会发现几乎不可能完全直线因为电机、轮胎、地面、电池电压都会有差异。这正是需要闭环的原因。但开环阶段的价值在于你可以先发现机械和电源层面的问题。如果开环时车就明显跑偏先检查左右轮转速、轮胎气压、车轴是否歪、底盘是否变形。这些机械问题如果不解决后面传感器闭环会反复抖动因为控制算法一直在补偿机械误差。当开环能走出相对稳定的直线后再接入传感器。先让车低速沿中线跑目标是保持在赛道中间不要求速度。等中线跟随稳定了再逐步提速。3.2 PID 调参的正确姿势每次只动一个参数PID 是智能车最常用的控制算法。很多人一听到 PID 就害怕其实可以把它理解成一种“误差消除策略”比例项告诉车当前偏了多少积分项把长期累积的偏差补回来微分项提前看趋势抑制振荡。一个基本的增量式 PID 伪代码如下int error target - current; integral error; int derivative error - last_error; int output Kp * error Ki * integral Kd * derivative; last_error error;调参第一步只调 P。先把 Kp 调到一个“误差大了能快速回正但车不抖”的程度。如果车左右摆动越来越厉害说明 Kp 太大如果过弯太迟钝说明 Kp 太小。第二步加一点 I。I 的作用是消除长期偏差比如车老是贴着赛道一边跑。先给一个很小的值不要贪I 太大会引起低频摆动。第三步加 D。D 能抑制过冲让车在进入弯道和中线附近更平滑。D 太大会放大噪声让舵机高频抖动。调参的时候最重要的原则是每次只改一个参数改完跑一圈记录现象。不要同时调三个参数否则你根本不知道是哪个参数导致了变化。3.3 坡道和过弯的稳定性编码器、陀螺仪和速度规划“飞檐走壁”体感最强烈的场景是坡道。很多车在平地上跑得好好的一到坡道就原地打滑或者冲出去。原因通常是速度环没有处理好或者电机扭矩不足。我建议在第一次参赛时给车加上编码器做速度闭环。有了速度反馈车才能在坡道上保持目标速度而不是靠 PWM 硬顶。坡道的处理方法可以这样进入坡道前检测到坡度或坡道入口主动平稳提速。上坡时保持电机输出稳定尽量不突然加减速。下坡时用电机拖曳或限制最大速度防止车速过快冲出赛道。过弯也要做速度规划。最简单实用的策略是直道加速弯前减速弯中匀速出弯再加速。判断弯道可以用图像中线误差的变化率或者陀螺仪的角速度。提前减速比在弯中大力刹车更稳定也更保护电机驱动。3.4 用串口日志把问题可视化第一次调试时最难的是“车跑飞了不知道哪里出了问题”。这时候不要靠肉眼猜。把关键变量通过串口打印出来是成本最低的调试方式。至少需要输出这些量当前采样到的传感器原始值。计算出的赛道中线误差。PID 输出的最终值。编码器测得的当前速度。电池电压。当前状态机状态比如直线、弯道、坡道。每一行日志都要带时间戳。这样回看时可以把现象和代码执行过程对上。现场调试如果不想被 USB 线拖着可以用无线串口模块但一定要注意延迟和丢包不能干扰车上主控。4. 比赛现场最容易翻车的事情现在就要开始准备备赛最后一个阶段很多人觉得车已经能跑完赛道了就松懈了。但真正到了现场环境变了压力变了各种以前没出现过的问题都会冒出来。第一次参赛现场稳定性比速度重要得多。4.1 环境变量光线、地面、坡道角度、发车位置赛场和实验室几乎没有完全一样的。灯光可能更亮地面可能更滑坡道角度可能略有不同甚至发车区的位置都会影响车的启动。所以比赛前要做“鲁棒性测试”在不同光线下采集传感器数据看图像亮度是否溢出、电磁信号是否饱和。在不同地面材质上测试比如瓷砖、木地板、短毛地毯。在不同电池电量下跑记录满电和低电量时的车速差异。在多个充电器下测电池充满时间不要到现场才临时充电。到了现场第一件事不是立刻跑高速而是先观察赛道并用同一套程序在不同区域低速试跑。如果发现某个路段总是出问题不要急着改代码先排查环境变量。4.2 排查链路从现象反推根因现场出问题时最容易慌乱。我建议每次遇到问题都按下面的顺序排查不要跳步看现象是跑飞、抖动、上坡无力还是直接不启动看传感器数据摄像头图像是否异常电磁值是否饱和编码器读数是否跳变看处理结果中线提取是否错误误差是否突变状态机是否切错看输出PWM 是否饱和舵机是否转向过猛驱动是否过热看执行机构转向拉杆是否松动轮胎是否卡滞电机插头是否松脱举个例子车在坡道前老是冲出赛道。按顺序查一遍最常见的原因是坡道入口的图像亮度过高导致中线提取错误或者下坡速度失控速度环还没跟上。这两类问题的修复方式完全不同前者要优化图像阈值后者要加限速和提前减速。4.3 现场降级方案比赛现场最忌讳临时调参。因为环境一变刚调好的参数可能又失效而且大面积改代码很容易引入新 bug。我建议在出发前就准备好三套参数激进参数目标速度高过弯晚减速适合赛道摩擦力和光线都比较理想时使用。稳定参数速度适中弯道提前减速适合大多数情况。保守参数速度缓慢所有策略都保守保证完赛优先。如果现场反复出现不稳定就果断切换保守参数。第一次参赛完赛本身就是胜利。不要为了圈速好看而冒险。代码层面备份一个“跑通版本”到多个 U 盘和云盘现场不要修改任何关键逻辑只允许调整几个参数宏。注意现场下载程序后一定要先目测检录和发车流程。很多队伍因为没看清发车方式直接把车放反导致第一轮成绩无效。5. 一次比赛真正沉淀下来的东西比赛结束那晚我们队只拿了个参与奖但整个备赛过程留下的东西比奖项更值钱。我后来带新队员时最想传递的也是这套方法论而不是某一行代码或某一个参数。5.1 一套可复用的调试流程把前面所有经验收束成一个框架就三条先把规则变成任务把任务变成可测指标。先从最小系统开始跑通一个环节再往下加复杂度。每次只改一个变量用日志和测试记录代替感觉。这个流程不只能用于智能车也能用于机器人、嵌入式课程设计、甚至很多软硬件结合的项目。核心思路不是“做一个完美的方案”而是“在有限时间和资源里让问题可复现、可定位、可修复”。5.2 专科队伍的劣势和优势专科学校第一次参赛劣势很明显没有学长传承基础课跨度大实验室设备紧张信息获取渠道少。但优势也很明显队伍里每个人往往都是因为真喜欢才留下的动手机会更集中试错成本更可控。我建议不要一上来就觉得自己不行而是把“零基础”变成“一张白纸”的优势。比如我们在读前几届技术报告时反而没有既有框架束缚更容易吸收不同队伍的思路。5.3 比赛之后还能做什么如果这次比赛能完赛下一阶段可以继续做三件事自动任务识别信标、二维码、颜色块把单纯的循迹升级为视觉决策。数据回放用车上的日志做一个离线播放器比赛后复盘每个弯道的速度曲线。参数自整定用简单的梯度搜索或模糊控制让调参不再依赖手工。更重要的是把参赛过程中的文档、代码、测试记录整理成一份完整的“智能车备赛手册”留给下一届学弟学妹。这样第二年再参赛时就不会再从零开始。一次比赛真正沉淀下来的不是一块牌子而是你把一件复杂工程拆成可执行步骤并且稳定复现出来的能力。“飞檐走壁”只是结果过程才是手艺。第一年别怕慢先做一个能稳定跑完的版本再把油门踩下去。