单人备赛智能车竞赛：蚂蚁搬家式任务拆解与工程实践指南

如果你在网上搜索“全国大学生智能车竞赛”大概率会看到很多队伍合影、实验室通宵、三个人围着赛道紧张调试的画面。这个比赛的默认设定似乎是“组队参赛”有人画板子有人写代码有人搭机械。但我想说的是另一种情况——当队伍里只有自己一个人的时候备赛会变成什么样子。我当时的答案是它变成了一场“蚂蚁搬家”。不是一天搬完一整袋大米而是每天只搬一小粒连续搬很久。今天看懂一个传感器中断明天调通一个串口打印后天让车在直道上不抖。看起来每件事都微不足道但三个月后回头看这辆车已经从一堆散装零件变成了能在赛道上跑完全程的机器。这篇文章不是成绩炫耀也不是劝退。它是一份写给“可能也正在一个人准备智能车竞赛”的备赛笔记。我会从竞赛认知、技术栈拆解、备赛节奏、调试方法、代码示例、常见问题这几个角度讲清楚一个人备赛时真正应该怎么推进。如果能让你少走一点弯路这篇记录就值了。1. 为什么说一个人的备赛是“蚂蚁搬家”先说结论一个人备赛智能车真正的难点不是编程不是电路而是任务粒度不够小。三个人备赛时任务可以按成员拆分有人管底层驱动有人管控制算法有人管机械和赛道。每个人只需要盯住自己负责的那一块遇到问题可以立刻找队友讨论。一个人的时候所有任务都会堆到你面前传感器为什么读不到数据舵机为什么打死轮胎为什么磨秃了电容为什么鼓包每一个问题都要亲自查、亲自试、亲自背锅。刚开始我很焦虑因为总想着“尽快把车调好”但“把车调好”不是一个任务而是一个虚无缥缈的终点。后来我想明白一件事蚂蚁搬家从来不是一次把粮食全搬完而是在固定时间内尽量多地完成“确定的小动作”。于是我把备赛流程重新定义成一条流水线今天只做一件事让单片机通过串口把距离数据打印出来。明天只做一件事让舵机能根据按键左右转动。后天只做一件事让车在直道上走稳 5 米。每一天结束哪怕只完成其中一件都算搬家成功。长期积累下来车就会从“不转”变成“能转”从“能转”变成“会看路”从“会看路”变成“能跑圈”。一个人备赛的优势和劣势同样明显建议你先摆正心态劣势优势知识面覆盖不全容易卡在未知领域决策链路短不需要开会就能改方案调试时没人帮忙盯车、看现象对整辆车每个细节都有完整的理解情绪绷不住时没人分担连续复盘效率高改完立刻测测完立刻改时间碎片化容易被杂事打断一旦形成自己的节奏执行力非常强所以这篇文章真正想解决的不是“怎么让车更快”而是“怎么让一个人也能把备赛这件事坚持到比赛日”。2. 先搞清楚智能车竞赛到底比什么很多新手踩的第一个坑不是技术不会而是对规则的理解太晚。智能车竞赛每年会发布新的赛题和规则不同组别的侧重点差异很大。有的组别偏向电磁传感与模拟信号处理有的组别偏向摄像头视觉识别有的组别偏向机械结构与动力控制还有创意组别会结合特定的 AI 平台和工业界工具链。以公开信息常见的组别来看负压电磁组强调电磁导航和车速控制摄像头组强调图像处理和赛道元素识别越野组强调机械通过性和路况判断创意组则更看重方案的完整度和创新点。在动手画板子或写代码之前必须做三件事找到当年官方发布的竞赛规则文档逐条读清楚。确认自己意向组别的技术限制允许用什么主控、什么传感器、什么车模。关注裁判系统、发车方式和成绩评定标准。在智能车圈里很多同学会关注到“卓晴”这个名字。卓晴老师每年都会发布对竞赛规则的详细解读和常见问题回复是备赛阶段非常重要的信息渠道。建议把它和你所在学校的指导老师、往届参赛队伍的经验帖一起纳入信息源。选组别这件事一个人备赛时尤其要想清楚。因为你的精力只够深入一条技术路线。如果你擅长嵌入式底层电磁组可能更容易起步如果你对图像处理和线元素识别感兴趣摄像头组会让你更有动力如果你希望作品更贴近产业应用可以关注创意组相关信息。这里给出一个人选组的参考维度维度建议技术基础没学过图像处理优先考虑传感器方案更直接的组别硬件条件确认实验室/宿舍能不能满足焊接、测量、改装需求参考资料优先选择往年资料多、社区活跃度高的组别时间预算视觉方案的学习曲线通常更陡需要预留更多时间想清楚这些再开工会比“先买一堆零件再说”稳妥得多。3. 一个人的技术栈拆解与补课路线智能车是一个非常典型的嵌入式综合项目。它不只是一块单片机开发板而是机械、硬件、软件、控制、调试五条线并行的系统。下面这个图景就是一辆车背后需要覆盖的技术栈。3.1 机械与装配车模到手后第一件事是装配和结构加固。很多新手容易忽略螺丝拧紧力矩、轮胎摩擦面清洁、底盘重心位置这些细节导致后续调控制参数时怎么调都抖。一个人做机械建议养成“拆一件拍一张照片”的习惯。因为所有零件都是你自己拆的如果装不回去没有任何人能帮你回忆原状。3.2 电路与硬件你需要看懂原理图至少要能定位电源、主控、电机驱动、传感器接口这些模块。最常见的硬件问题不是“烧了”而是虚焊和接触不良。一个人的建议把万用表用到极致。测通断、测电压、测电流很多看起来像软件的问题最后都是因为杜邦线松了或者焊点裂了。3.3 单片机与嵌入式 C主控是整个系统的核心。你需要掌握 GPIO、定时器、中断、ADC、PWM、串口这些基础外设。市场上大多数学习板都有参考例程但不要只复制要尝试自己重写一遍初始化流程。3.4 传感器与视觉根据组别不同你会用到电磁传感器、摄像头、灰度传感器、激光测距模块等。摄像头方向需要理解图像二值化、赛道边线提取、元素识别这些概念电磁方向需要理解信号放大、归一化、电感排布与差比和计算。3.5 控制策略与 PID很多人的车第一次跑起来时都像“喝醉了”这是因为开环给油门车只会冲。PID 是最基础、也最有效的闭环控制方案。它不神秘就是根据误差计算修正量让实际值向目标值收敛。3.6 调试工具与上位机智能车调试不只是“下载代码-上电-看车跑”。你需要学会看波形、看日志、录像回放。在很多工程里串口上位机和屏幕波形显示工具能帮你在车跑出去之前先确认数据是否合理。把这六块列出来不是让你在比赛前全部精通而是让你意识到一个人备赛时不必要求自己在每个方向都成为专家但每个方向都要建立“能跑步的底座”。遇到哪一块不会就把它当成蚂蚁搬家中的一个小任务安排到当天计划里。4. 把备赛拆成“蚂蚁能搬完的小任务”既然叫“蚂蚁搬家”就得有搬家的节奏感。我建议把整个备赛过程划分成六个阶段每个阶段都有明确的验收标准。没有验收标准的阶段很容易陷入“每天都很忙但车没有进步”的困境。阶段主要任务验收标准核心风险阶段一信息调研、规则研读、组别确认能做出一张技术选型表盲目下单买错硬件阶段二最小系统跑通板子上电程序下载成功LED闪烁可控开发环境与驱动问题阶段三传感器数据可读串口能稳定输出有效数据接线错误、滤波参数不合理阶段四执行机构可控舵机、电机能根据输入指令动作PWM频率或极性配置错误阶段五闭环控制起步车能沿直线稳定行驶一段距离PID参数不匹配导致振荡阶段六综合调优与稳定性能连跑多圈不翻车不完全出界赛道元素识别不稳定每个阶段的持续时间因人而异。如果卡住了不要原地死磕超过两天。蚂蚁的智慧是绕路不是硬扛。换一条技术路线、问一次老师、查一篇经验帖往往比继续猜更有效。一个人备赛时最危险的是“沉没成本心态”已经在这个方案上花了三天不想换。但智能车的目标不是“证明某个方案正确”而是“让车顺利跑完”。方案不好就换这是竞赛策略不是失败。5. 把调试变成一套工程流程一个人最大的敌人是“改了哪里忘了记录”。三分钟后你就忘了刚才车轮抖到底是因为 kp 调大了还是因为电池电压低了。所以一个人的备赛比团队更需要工程化。哪怕是只给自己看也要有版本管理、参数文件和调试日志的意识。5.1 用 Git 管理代码不要把代码只放在本地文件夹里至少用 Git 做版本管理。比赛前的某个深夜你会感谢那个三周前保存了“能跑版本”的自己。# 初始化代码仓库在你工程目录下执行 git init git add . git commit -m init: 最小系统跑通LED闪烁正常 # 每次改动一个功能提交一次 git add src/main.c git commit -m feat: 增加串口输出传感器原始值 # 调坏了大不了回滚 git log --oneline git checkout commit_id -- src/main.c一个人也要养成写 commit message 的习惯。不要求写得多规范至少能让自己看懂这次提交到底改了什么。5.2 参数配置文件化很多新手把 PID 参数直接写成全局变量每次改参数都要重新编译下载。更建议把需要经常调试的参数集中管理单独放到一个头文件或配置结构体里改起来方便也不容易遗漏。// 文件路径config/car_config.h #ifndef CAR_CONFIG_H #define CAR_CONFIG_H typedef struct { float kp; float ki; float kd; float target_speed; } speed_pid_t; // 所有需要经常调的参数集中在这里 typedef struct { speed_pid_t speed_pid; float steer_pid_kp; float steer_pid_ki; float steer_pid_kd; uint16_t camera_threshold; } car_config_t; extern car_config_t g_config; #endif参数文件不是银弹但它能把“改参数”这件事变成一种低成本操作。调车频率会高很多因为你不怕改了之后回不去。5.3 用串口打印关键数据一个人调试时你的眼睛不能总盯着车还要盯数据。把传感器原始值、PID 输出、当前偏差通过串口打印出来很多问题会变得非常直观。// 文件路径debug/uart_debug.c #include stdio.h // 这个函数由你的硬件 SDK 提供功能是发送一个字节 void uart_send_byte(char c); int fputc(int ch, FILE *f) { (void)f; uart_send_byte((char)ch); return ch; } // 使用示例 void debug_print_sensor(uint16_t distance_cm) { printf([SENSOR] distance%u cm\r\n, distance_cm); }有人觉得 printf 在嵌入式里太慢但作为调试手段它足够好用。真正发布比赛版本前再考虑优化打印频率也不迟。5.4 维护一份调参记录表推荐用最简单的表格记录每次调参。不需要复杂工具一张 Markdown 表格或 Excel 都行日期修改内容车速现象结论2025-XX-XXkp 0.3-0.51.0m/s直线抖动继续观察可能 pid 周期不一致2025-XX-XX增大电机油门斜坡时间1.0m/s起步不再甩尾保留此方案这份记录的意义是当你某天突然找不到问题原因时翻记录比重新猜高效十倍。6. 传感器与控制代码示例下面给出两个比较通用的代码框架帮助你理解智能车“感知-决策-执行”链路中的关键环节。注意这些代码不是某个厂商 SDK 的完整实现而是参考思路你需要根据自己使用的单片机和外设进行适配。6.1 传感器读取滑动平均滤波原始 ADC 数据往往带有噪声直接使用会让控制量抖动。滑动平均滤波是最简单也最常用的处理方式。// 文件路径src/filter.c #include stdint.h #define FILTER_N 8 static uint16_t filter_buf[FILTER_N]; static int filter_index 0; void filter_init(void) { for (int i 0; i FILTER_N; i) { filter_buf[i] 0; } } // 每次传感器采样后调用得到平滑后的值 uint16_t filter_push(uint16_t raw_value) { filter_buf[filter_index] raw_value; filter_index (filter_index 1) % FILTER_N; uint32_t sum 0; for (int i 0; i FILTER_N; i) { sum filter_buf[i]; } return (uint16_t)(sum / FILTER_N); }使用思路在 ADC 转换完成中断里取原始值喂给filter_push()用返回值做后续控制。滑动窗口长度可以调整窗口越长越平滑但延迟也越大需要根据车速试验。6.2 控制核心增量式 PIDPID 是智能车中最常见的控制算法。增量式 PID 输出的是“这次相对于上次的增量”适合舵机和电机这类执行机构。// 文件路径src/pid.c typedef struct { float kp; float ki; float kd; float target; float err_prev; float integral; } pid_t; void pid_reset(pid_t *pid, float target) { pid-target target; pid-err_prev 0.0f; pid-integral 0.0f; } float pid_update(pid_t *pid, float current) { float err pid-target - current; pid-integral err; float p_out pid-kp * err; float i_out pid-ki * pid-integral; float d_out pid-kd * (err - pid-err_prev); pid-err_prev err; return p_out i_out d_out; }使用思路每个控制周期调用一次pid_update传入当前车速或当前偏差返回输出值叠加到执行机构上。调参顺序建议先调kp让系统有响应再加kd抑制超调最后加少量ki消除稳态误差。如果你发现引入ki之后系统开始振荡通常是因为积分项累积过快可以限制积分范围或者只在误差较小时启用积分。6.3 通过 JSON 管理调参目标如果你使用上位机或树莓派等 Linux 平台做图像处理可以尝试把参数文件单独管理车端通过通信协议读取参数避免反复交叉编译。{ car: { max_speed: 1.8, turn_speed: 0.9 }, pid: { kp: 0.32, ki: 0.02, kd: 0.08 }, camera: { exposure: 200, threshold: 128 } }这不是一个可以直接被单片机消费的格式但它为你的调试工具链提供了一个清晰的“参数约定”。如果你正在做创意组或结合 Linux 平台的项目这种设计能让你的参数管理干净很多。7. 运行结果与效果验证代码写了怎么判断它真的有效不能只看“编译通过”智能车项目必须在真实设备和赛道上验证。建议按下面的顺序逐级验证7.1 验证串口输出烧录串口调试代码后打开串口助手波特率和代码配置一致。预期输出类似[SENSOR] distance23 cm [SENSOR] distance24 cm [SENSOR] distance23 cm如果输出值稳定且在合理范围内说明传感器读取链路是通的。如果输出跳到零或满量程先检查接线和供电。7.2 验证滤波效果把车放在静止状态下观察滤波前后的输出。预期是原始值有波动滤波值波动明显变小。如果滤波后依然剧烈抖动考虑窗口长度是否太小或者传感器供电是否稳定。7.3 验证 PID 响应把车架起来让后轮悬空给一个目标速度观察轮速是否能快速收敛到目标值。如果转速一直振荡先降低kp把比例增益调小如果响应太慢适当增大kp。7.4 上赛道综合验证把车放到直道上从 20% 油门开始跑。如果跑直道都画龙先不要急着提高速度调好直道再测弯道。每次切换速度档位必须重新验证一轮稳定性。一个很重要的验证原则先求稳定再求速度。能稳定跑完一圈速度是后面慢慢提的事情跑得快但每圈都飞出去比赛成绩一定不好。8. 单人备赛常见问题与排查一个人备赛很容易陷入“出问题-乱改-更糟”的循环。下面是几个高频问题的排查思路。问题现象可能原因排查方式解决方案程序下载失败开发环境驱动未装、开发板选择错误查看下载工具报错信息重装驱动核对开发板和调试器型号串口没有输出波特率不匹配、串口引脚接错用示波器或逻辑分析仪查看 TX 引脚波形核对硬件原理图确认串口引脚和波特率电机不转但单片机在跑电机驱动使能引脚未配置、电池电压不足测量驱动板输入输出引脚电压检查使能信号更换充满电的电池舵机打死或抖动PWM 频率不匹配、占空比超范围打印 PWM 占空比观察舵机响应按要求设置 PWM 频率限制输出范围直线行驶画龙PID 参数不当、转向响应延迟通过串口打印偏差和输出值从纯 P 控制开始调再逐步加入 D摄像头图像花屏硬件接线过长、供电不足、时序配置错误降低分辨率检查摄像头排线缩短排线长度独立供电重新初始化时序一组参数今天能用明天不能用电池电压下降、光线变化、机械件松动对比调参记录检查机械紧固件参数设置留冗余比赛前避免大幅改结构遇到问题时按“软件-硬件-机械-环境”的顺序排查。不要一上来就怀疑算法先确认传感器读数是不是真的。9. 工程建议与经验总结一个人备赛也需要一套自己的工程纪律。以下是我认为最重要的几条。9.1 每天留下可回退的版本比赛备赛周期长状态波动很正常。你今天觉得“这个方案很有希望”明天可能就发现是死路。如果没有版本管理你会连“回到昨天那个还不错的版本”都做不到。9.2 建立自己的知识仓库一个人没有队友互相提醒很容易“学完就忘”。建议把解决的问题、查到的资料、踩过的坑集中记录在一个笔记里。不需要整理得多漂亮关键是能搜索、能回顾。9.3 重要资料双机备份代码、原理图、论文、比赛文档这些资料至少备份两份。实验室电脑、个人笔记本、云盘任意两个组合都可以。比赛前一周电脑突然坏了是真实发生过的故事。9.4 注意设备与操作安全备赛涉及电池、烙铁、切割工具和高速运转的小车安全不能忽视。锂电池充放电要有人在场焊接注意通风车辆测试时不要让轮胎接触衣物和手指赛道测试区域要清空无关物品。9.5 及时和导师与同学沟通一个人备赛不等于闭门造车。指导老师的一句话、往届学长的一次演示可能省掉你一周的弯路。不要因为“问题太基础”而不敢问。在竞赛这种场景里快速获取可靠信息本身就是核心能力。9.6 保持稳定的作息智能车备赛非常容易进入“通宵-睡半天-没效率”的恶性循环。但实际上控制策略调试需要清醒的头脑。一个稳定的作息比最后三天的突击有用得多。10. 写在最后蚂蚁搬家的道路方向比速度重要回到这篇文章的标题。大一一个人选择了一条看起来需要很多人一起走的路。蚂蚁搬家看起来慢但它有一个值得借鉴的地方蚂蚁不会停下来思考“这条路还有多远”它只负责把当前这一粒粮食搬回巢。智能车备赛也是这样。你不会在第一天就看到一辆能上赛道的车你只会看到一堆零件和很多报错。但如果你坚持每天搬到几粒“有用的沙子”——一段能跑的代码、一条稳定的数据曲线、一次成功的过弯——这些沙子最终会堆成一辆属于你的车。如果你的学校有队友请务必组队但如果你的处境真的只有一个人也请不要急着放弃这个比赛。备赛过程中的收获往往不只在获奖证书上。你会更了解代码、电路、机械和控制也会更了解一件事当没有人给你兜底时人到底能爆发出多少执行力。把目标变小把记录做好每天搬一点。比赛那天把车放上赛道的那一刻你会发现蚂蚁走过的路虽然慢但真的能到终点。建议收藏这篇文章备赛中途想放弃时翻出来看看。