智能车竞赛新手备赛指南：从零到稳定完赛的完整路线图

每年智能车竞赛的获奖名单公布后，搜索“国赛名单”“获奖名单”的人总是一拨接一拨。对于第一次带队或第一次参赛的专科学校队伍来说，这份名单更像一面镜子：别人跑完一整圈毫无压力，自己的车还在发车区原地转圈。于是很多队伍带着“佬们轻点虐”的心态进群求教，却发现连问题都不知道怎么问。

这篇文章想聊的，不是某一个具体组别的调参秘诀，而是“第一次参加智能车竞赛，究竟该怎么准备才不会白忙一场”。我会结合“飞檐走壁”这类高速跑图项目的备赛逻辑，拆解团队分工、硬件选型、视觉循迹、控制调试、元素处理和比赛策略，尽量让第一次参赛的队伍能形成一条可执行的路线图。

先说一个明确判断：第一次参加智能车，目标不应该是“拿奖”，而应该是“稳定完赛，跑出完整赛道”。别小看这个目标，很多经验丰富的强队翻车也翻在“求快”上。一个能稳定识别元素、靠谱跑完全程的车，已经能跑赢相当一部分临时拼凑的队伍。

1. 为什么第一次参加智能车容易被“虐”：差距到底在哪

很多专科院校的参赛队伍，第一次听到“智能车”三个字，脑海里的画面是机器人大赛、高深算法、密密麻麻的电路板。真正入坑之后才发现，这个比赛的难点不在于某一个“高大上”的技术，而在于它要求你同时搞定机械、电路、嵌入式、控制、图像处理、现场调试六件事。

强校队伍之所以看起来“很猛”，核心原因不是他们的芯片更贵，也不是天赋异禀，而是传承。他们手里的代码库、结构件、调参记录、技术报告模板，都是前几届队员一版一版沉淀下来的。新人入队，第一周就能站在前人的肩膀上跑起来。而第一次参赛的专科队伍，往往从零开始，连“上电之后车为什么不动”都要排查三天。

这种差距确实存在，但它不是不可逾越的。因为智能车竞赛的开源资料非常多，历届技术报告、开源库、教学视频、优秀学长经验帖，几乎覆盖了所有常见问题。第一次参赛真正缺失的不是“资料”，而是把资料转化为自己工程能力的方法。网络搜索热词里常年出现的“智能车走马观碑手册”“智能车国赛名单”，都说明这个圈子有很强的资料共享文化，关键看你会不会用。

以“飞檐走壁”这类跑图项目来说，它既考速度，又考稳定性。很多队伍平时在实验室跑得很好，一到比赛现场就放飞自我，坡道冲太快直接翻车，摄像头被颠得丢线，最终成绩反而比慢跑的队伍差。第一次参赛的队伍如果把“稳定完赛”当作第一目标，在整个备赛期间都会少走很多弯路。

2. 智能车竞赛的底层逻辑：先理解规则再谈技术

智能车竞赛本质上是一个“规则理解 + 工程实现 + 极限调试”的综合比赛。比赛会规定赛道环境、车模类型、传感器限制和任务目标，你的车要在规定时间内完成赛道遍历，识别指定元素，用时越短、完成度越高，成绩越好。

很多人一上来就抱着“我要用深度学习做目标识别”的雄心壮志，这其实是对比赛规则理解不够。从历年的比赛设置来看，不同组别对传感器的限制差异很大：有的组别以摄像头为主，赛道元素包括环岛、十字、坡道、断路、锥桶等；有的组别以电磁传感器为主，更考察信号处理和硬件排布；还有部分创意组或视觉组会引入更复杂的任务逻辑。以“飞檐走壁”这个赛项名来说，它更接近高速连贯跑图，车模要在坡道、快速弯道和连续元素中保持稳定，对图像稳定性、控制鲁棒性、元素状态机的设计要求都很高。

下面用一张表来概括各组别的特点，方便第一次参赛的队伍做选型判断：

第一次参赛，最怕的不是选错组别，而是不看规则，全靠猜。每年都有队伍在比赛前才发现自己的车模不符合规格，或者使用的传感器超出了组别限制。这里必须强调：不同年份、不同赛区的规则细节可能有调整，务必要以当年官方发布的竞赛规则为准，不要轻信网传截图和二手消息。第一次参赛的队员，第一个任务就是通读规则原文，把“能做什么、不能做什么”整理成一张自查表。

3. 第一次参赛的团队组建与硬件准备

智能车不是一个人的“英雄主义”，而是一个小团队的工程协作。第一次参赛，建议队伍人数控制在2到4人。人太少忙不过来，人太多又容易职责不清，出现“三个人都改同一个文件”的尴尬局面。

比较靠谱的分工方式是这样的：

• 机械与硬件负责：车模组装、传感器支架设计、走线、电源分配、电机驱动接线。
• 嵌入式软件负责：主控芯片工程搭建、图像采集、控制算法、代码调试。
• 算法与策略负责：图像处理逻辑、赛道元素状态机、特殊任务识别。
• 测试与记录负责：实车测试、录像记录、调参表格整理、现场比赛策略制定。

注意，分工不代表各干各的。机械和算法之间最容易脱节：摄像头装高了，图像视野好看，但车过弯时重心不稳；摄像头装低了，图像稳定，但远瞻性差。第一次参赛的队伍，每周至少要集中联调两次，把机械调整和代码策略放在一起验证。

硬件层面的基础配置，一般包括车模、传感器、主控芯片、电机驱动、舵机、电源模块和调试工具。第一次参赛不需要追顶级硬件，很多队伍用常规车模和主流MCU一样能跑出不错的成绩。选购时要注意兼容性，比如电机驱动是否支持你的主控电平、舵机供电是否稳定、电池放电能力是否足够。不要为了“看起来很强”盲目堆配置，硬件稳定性永远排在性能前面。

配套工具方面，IDE、仿真器、虚拟示波器、无线透传模块和录像设备是刚需。智能车调试的最大痛点是“车在跑，你看不到它的内部状态”。用无线透传把图像二值图、中线偏差、PID输出实时发到电脑上，比事后猜测高效得多。这也是很多强队调车效率高的原因。

4. 软件环境与工程结构：让代码可维护

第一次参赛的队伍，代码往往是从网上下载的工程模板改来的，一个main.c里面塞了两千行，变量名从a1写到a10。前期确实能跑，但一旦开始迭代调参，问题就全暴露了：改一个阈值，不知道影响了哪里；出问题想回退，却没有版本记录。

建议从第一天开始就建立清晰的工程结构。下面是一个比较通用的目录组织方式，具体MCU平台不同会有差异，但模块化思路是共通的：

project/ ├── libraries/ # 底层库，如摄像头驱动、PWM、串口、GPIO ├── modules/ # 功能模块，如图像处理、PID控制、状态机 │ ├── img_process.c │ ├── img_process.h │ ├── control.c │ └── control.h ├── user/ # 主逻辑 │ ├── main.c │ └── isr.c ├── doc/ # 调参记录、接线图、规则自查表 └── build/ # 编译输出目录

代码文件要按模块拆开，每个模块只做一件事。比如图像处理模块只负责“灰度图到中线”，控制模块只负责“偏差到舵机PWM”。模块之间用接口连接，这样某一部分出问题时，可以快速定位，不会牵扯到全部代码。

第一次参赛还应该尽早使用版本管理工具，哪怕只有两个人协作，Git也值得用起来。不要每天用“final_v1.c”“final_v2.c”这种命名法，学会用Git做一次提交记录，每次实车测试跑出效果后提交一次，写清楚改动内容，比如“左右转弯PID的D参数从25改成40，效果是过弯更顺”。这样出现问题回退时，你的依据不是模糊的记忆，而是明确的提交记录。

IDE和编译环境以你选择的主控平台为准，不同平台的工程创建方式差异较大，这里不展开。核心建议是：在开始写业务代码前，先把串口打印、LED指示这类基础调试接口打通，它们是你后续排查问题的“眼睛”。

5. 摄像头循迹的最小系统：从图像到转向

摄像头组别或视觉类组别，核心链路离不开“图像采集 -> 二值化 -> 找中线 -> 计算偏差 -> PID输出方向”。这套流程看起来简单，但每一步都有坑。下面用一个最小示例把链路讲清楚。

第一步，把灰度图转成二值图。赛道一般由深色线和浅色底组成，二值化的本质就是设定一个阈值，让大于阈值的像素变成1，小于阈值的像素变成0。这里的关键是阈值怎么取。固定阈值在光线稳定的实验室里够用，但比赛现场灯光复杂，更推荐动态阈值或大津法。先看固定阈值版本：

// 文件路径：modules/img_process.c #define IMG_W 188 #define IMG_H 120 #define THRESHOLD 80 uint8_t gray[IMG_H][IMG_W]; // 原始灰度图，由摄像头驱动填充 uint8_t binary[IMG_H][IMG_W]; // 二值化后的图像 void binarize(uint8_t threshold) { for (int row = 0; row < IMG_H; row++) { for (int col = 0; col < IMG_W; col++) { binary[row][col] = (gray[row][col] > threshold) ? 1 : 0; } } }

第二步，是找到每一行的赛道中线。这里按“灰度值大于阈值视为赛道”的假设来处理。常见的做法是从左右两侧向中间扫描，找到第一个满足条件的像素点，然后取二者的中点。如果某一侧找不到边界，说明这一行丢线了，需要返回一个特殊值，由上层策略决定如何处理：

// 在每一行中找左右边界并计算中线 int find_center_line(int row) { int left = -1; int right = -1; for (int col = 0; col < IMG_W; col++) { if (binary[row][col] == 1) { left = col; break; } } for (int col = IMG_W - 1; col >= 0; col--) { if (binary[row][col] == 1) { right = col; break; } } if (left == -1 || right == -1) { return -1; // 该行丢线 } return (left + right) / 2; }

第三步，把中线和参考值的偏差交给PID控制器。方向环和速度环是智能车控制的两个核心环节，其中方向环直接决定车能不能跑稳。先看方向环的简化实现：

// 文件路径：modules/control.c float kp_dir = 0.8f; float kd_dir = 1.5f; float last_dir_error = 0.0f; float direction_pid(float target_center, float actual_center) { float error = target_center - actual_center; float p_out = kp_dir * error; float d_out = kd_dir * (error - last_dir_error); last_dir_error = error; return p_out + d_out; // 返回舵机PWM增量或角度值，具体根据驱动方式定 }

速度环的目标，是让车在不同赛道段有不同的期望速度。比如直道加速、弯道减速、坡道保持稳定。第一次调车时，建议先固定一个较低的速度，只把方向环调稳定，再逐步加速度。

需要注意，PID只是最基础的控制方案。第一次参赛用PID足够，但不要迷信参数越大越好。D参数过大会让舵机高频抖动，I参数在电机环中可以消除静差，但如果积分饱和反而会让车在过弯时反应迟钝。调参时一次只改一个参数，改完跑一圈，用录像和串口数据对比效果，不要在车上拍脑袋乱调。

6. “飞檐走壁”跑图的元素处理与状态机

比赛赛道不是纯弯道和直道，而是由各种元素组合起来的。坡道、坎、连续弯道、十字、圆环，每种元素都有不同的几何特征。对“飞檐走壁”这类偏向高速连贯跑图的项目来说，最怕的是元素还没来得及判断，车就已经冲过去了。

所以元素处理的第一步，不是识别，而是状态管理。赛道元素处理最稳妥的思路是用一个状态机，把车当前处于什么赛道状态记录清楚，不同的状态使用不同的控制策略。下面用一个简化状态机来示意：

// 文件路径：modules/track_state.c typedef enum { TRACK_NORMAL, // 普通赛道 TRACK_RAMP, // 坡道/起伏段 TRACK_CROSS, // 十字路口 TRACK_RING // 圆环（如果规则包含） } track_state_t; track_state_t state = TRACK_NORMAL; // 判断条件函数，需根据实际图像特征实现 int is_ramp_detected(void); int is_cross_detected(void); int is_ramp_finished(void); int is_cross_passed(void); void track_state_update(void) { switch (state) { case TRACK_NORMAL: if (is_ramp_detected()) { state = TRACK_RAMP; } else if (is_cross_detected()) { state = TRACK_CROSS; } break; case TRACK_RAMP: if (is_ramp_finished()) { state = TRACK_NORMAL; } break; case TRACK_CROSS: if (is_cross_passed()) { state = TRACK_NORMAL; } break; default: state = TRACK_NORMAL; break; } }

状态机的好处是，把“这一段赛道应该怎么处理”和“当前实际是什么赛道”解耦开。比如在坡道状态，你需要压低速度或提前开坡，避免飞坡后落地不稳；在十字状态，不能按照普通弯道的中线逻辑去跟踪，否则很容易误判方向。

识别元素的关键，是要用“连续多帧确认”而不是“单帧断言”。比赛现场光线变化、图像噪声、坡道颠簸都会导致某几帧出现异常。同一个元素特征连续出现5帧、10帧再确认，误判率会大幅下降。这个思路看着简单，但很多队伍就是因为某个元素“偶尔识别到、偶尔识别不到”，在赛场上栽了跟头。

另外，元素处理的策略要区分“绝对可靠”和“尽量别误判”。第一次参赛，宁可漏识别一个元素，也不要误判一个元素。漏识别最多扣分或罚时，误判很可能直接导致车冲出赛道，轻则浪费时间重跑，重则直接退赛。先求不误判，再优化识别速度，这是最稳的推进路线。

7. 调试流程：先完赛，再求快

调试智能车，最忌讳“一上来就全图高速跑”。正确顺序是由静到动、由简到复杂，每一步都确认无误再往前走。下面是一条适合第一次参赛队伍的调试路线。

第一步，硬件自检。上电后先确认各个模块电压正常、舵机转动范围合适、电机能正反转、摄像头画面无花屏。这一步不要写算法，先确保硬件没毛病。

第二步，静态图像调试。把车拿在手里，推着车走赛道，观察二值化效果和中线提取是否稳定。重点尝试不同光线条件，把动态阈值或二值化参数调到一个比较鲁棒的区间。

第三步，低速直线循迹。让车以很慢的速度在直道上跑，确认它能沿着赛道中线直行，不左右画龙。如果画龙，优先检查摄像头中线和PID方向环，其次检查舵机安装是否松动。

第四步，弯道调试。逐步加入弯道，观察过弯是否流畅、有没有切内线或冲出赛道。过弯不稳时，先降低速度，再微调PID参数。这里最容易犯的错误是“方向环调不好就猛加D参数”，结果舵机高频抖动，反而更不稳定。

第五步，元素调试验证。单独测试每一个赛道元素，用录像记录车在每个元素上的表现。每改一次代码或参数，就重新录一段视频，标注好“版本、参数、现象”。

第六步，全图连续跑。把小元素串起来，让车完整跑一圈。第一次全图跑，目标只有一个：不断线、不冲出赛道、不卡死。

全图跑通之后，才进入“提速度”阶段。提高速度的策略不是无脑给油门，而是先找到当前最大的瓶颈。比如过弯总是压路肩，就先优化弯道策略；坡道后总是飞太远，就增加坡道前的减速点。一次只优化一个环节，跑完一圈对比全部时间，确认这次改动是真的有效，再继续下一次。

现场比赛还有一个常被忽视的点：电池状态。很多队伍在实验室用满了电的电池测试，到现场换上一块旧电池，车的响应完全不一样。建议备赛后期专门测试不同电量下的车速变化，比赛时优先使用充放循环状态良好的电池，并且在大赛前完成一两次完整的“模拟比赛流程”测试。

8. 常见问题与排查思路

第一次参赛，会遇到大量想不到的故障。这里把最常踩的几个坑整理成一张排查表，遇到问题时可以按顺序自查。

这张表不能覆盖所有问题，但它给出一个很重要的原则：排查问题要沿着“信号链路”逐步检查，而不是瞎猜。摄像头画面不对，先看硬件图像，再看二值化，再看中线，再看控制输出，每一层都先用打印或示波器确认，别跳到最后一层改代码。

现场调试时，建议把“上一次能跑的版本”牢牢记住。比赛现场环境复杂，任何临时改动都有风险，除非有充分把握，否则不要在赛前最后一小时大改算法。很多时候，保守运行比冒险激进成绩更好。

9. 第一次参赛的正确心态与备赛策略

“佬们轻点虐”是很多新队伍的内心独白，但真正进入比赛状态之后会发现，竞技场上没有人会因为你来自什么学校就手下留情。这个现实听起来残酷，其实对第一次参赛的队伍反而是好事：它逼着你把注意力放回技术和工程本身。

第一次参赛最容易犯的心态错误，是把别人分享代码当作救命稻草。很多队伍在备赛初期到处求代码，拿到手直接烧录，车跑不起来就再换一份。这种“代码拼凑式”备赛，哪怕最后勉强完赛，赛后你依然什么都不会。正确的方式是“先把流程跑通，再理解每一步为什么这样设计”。比如拿到一份图像处理代码，先把它跑起来，然后用串口把每一帧的中线打印出来，对照图像观察，看到算法失效的场景，再回去读源码，改一版适合自己的参数。这个过程才是真正的成长。

第一次参赛应该给自己设定一个可考核的目标链。备赛第一个月，完成硬件组装和环境调试；第二个月，完成稳定直线和弯道；第三个月，完成元素识别和全图跑通；最后一个月，优化速度并模拟比赛。每完成一个目标，做一次技术复盘，把结论写进文档。这样到比赛现场时，你对车的理解深度，和第一周完全不是同一个层次。

赛后复盘往往比比赛本身更重要。无论最终成绩如何，把这一年的代码、参数记录、技术报告、踩坑总结整理归档，对学校后续参赛是一种宝贵的传承。很多强队之所以每年都很强，就是因为每一届队员都在帮下一届队员扫雷。第一次参赛的队伍，即使成绩不理想，只要把这份“踩坑地图”保留下来，就已经给下一届队伍创造了巨大的价值。

关于后续学习方向，如果比赛用的是传统视觉为主的车，建议深入学一下串级PID、图像滤波、动态阈值这些内容；如果以后想往更高阶的视觉组发展，可以关注深度学习目标检测方向，比如用轻量级网络在嵌入式平台上做锥桶、目标物识别。智能车竞赛只是起点，它培养的工程思维和调试能力，在自动驾驶、机器人、嵌入式开发等方向都会持续发挥价值。

最后给第一次参赛的队伍一个建议：把车调稳、把规则吃透、把团队节奏带好，远远比追求极限速度更划算。赛场上真正让你遗憾的，往往不是“跑得不够快”，而是“明明能完赛，却在某个不起眼的小坑里翻了车”。愿你们的车能稳稳跑完第一圈。