大一的智能车备赛如果一开始就有人告诉我“你一个人选蚂蚁搬家大概率要熬夜到掉头发”我可能还是会选它。原因很简单这个赛题不是单纯的循迹跑圈它把视觉识别、运动控制、任务调度、机械设计全揉在一起。一个人备赛意味着每个环节都得自己摸一遍但这恰恰是成长最快的方式。这篇文章不写获奖心得只记录一个低年级学生在“一个人”这个条件下怎么把蚂蚁搬家从零开始做起来踩了哪些坑最后验证了什么。1. 蚂蚁搬家赛题速览在智能车竞赛里蚂蚁搬家属于任务型赛题核心是让小车自动执行“取物—搬运—放置”这一类完整闭环任务。它和纯竞速组最大的区别是速度不是唯一指标稳定完成任务、避免误判、在有限时间内提高效率才是重点。能力项说明赛题类型任务型智能车赛题模拟搬运场景核心任务识别目标物块、运动到指定位置、夹取/搬运、放置到目标区域主要硬件竞赛车模底盘、主控 MCU、摄像头/传感器、电机驱动、搬运机构软件技术栈嵌入式 C/C、图像处理、PID 控制、状态机调度调试重点视觉识别的稳定性、定点停靠精度、机械爪的可靠性、任务切换逻辑适合人群有一定单片机基础愿意花时间独立调试软硬件的学生团队规模通常 1-3 人个人备赛对时间管理和问题定位能力要求更高从备赛角度看蚂蚁搬家最突出的特点是“软硬结合”。它不像纯摄像头组那样只盯着赛道线也不像创意组那样有较多上位机计算资源可以依赖。它是一个典型的嵌入式实时系统传感器数据进来控制器必须在几十毫秒内做出决策然后驱动执行机构完成动作。大一学生选这个题等于提前接触了真实产品开发里的完整流程。2. 个人备赛的定位与边界一个人备赛首先要清楚自己的优势和劣势。优势是决策链路短。机械、电路、代码全在自己手上改一个参数不需要跟队友一遍遍对齐试错效率在初期反而高。劣势也很明显任何一个模块卡住整个进度就停摆。视觉识别调不出来运动控制就没法联调机械结构没装好代码逻辑再完美也跑不了真实任务。所以个人备赛最关键的不是技术多深而是把任务拆成小块每个小块都有独立的验证手段。这里要明确一个边界蚂蚁搬家这类赛题每年规则细节会有调整比如场地尺寸、物块数量、允许使用的传感器类型。文章中提到的方案只是通用工程路径比赛前必须以组委会发布的规则为准。另外如果比赛要求使用指定主控或指定软件框架一定要提前确认避免自己心血来潮选一套完全脱离竞赛规则的技术路线。3. 备赛前的环境准备与前置条件3.1 软件环境个人备赛建议先从一套最简开发环境开始不用追求复杂工具链。我采用的是“Windows 写代码 Ubuntu 做图像调试”的配合方式。单片机部分用 Keil 或者 STM32CubeIDE 都可以看学校实验室主流工具是什么。图像算法调试阶段Ubuntu 下的 OpenCV 环境明显比 Windows 更顺手。如果不想装双系统直接用虚拟机跑图像处理的单文件测试也够用。常用软件清单STM32CubeMX生成初始化代码。Keil / STM32CubeIDE编写主控逻辑。VS Code写图像处理脚本、文档记录。OpenCV做物料颜色/形状识别的前期验证。串口调试助手查看实时输出。逻辑分析仪排查电机驱动通信时序。3.2 硬件清单蚂蚁搬家需要一套完整的车模平台不是只买一块开发板就能解决的。基础硬件竞赛车模底盘包含驱动电机和转向机构。主控 MCU建议选择学校常用的 STM32 系列资料多Debug 方便。摄像头模块用于识别搬运目标和场地标记。编码器测量车轮转速为 PID 提供反馈。电机驱动模块大电流输出要稳定。电源模块把电池电压稳定给主控、摄像头、电机驱动分开供电。搬运机构这是蚂蚁搬家最核心的机械部分常见方案有机械爪、舵机推杆、电磁铁吸附、传送带具体选择要看比赛允许范围。机械部分如果学校有 3D 打印机可以自己设计夹爪没有的话先用舵机加铝型材搭个简单结构不要一开始就追求完美。3.3 调试场地没有场地智能车就是一堆零件。不要等到比赛临近才找场地。大一备赛最容易被忽视的其实是场地复现赛道尺寸、物块位置、光照条件都需要尽可能接近正式比赛环境。如果实验室场地紧张可以用 KT 板自己铺一块小场地。关键不是面积而是把“取物区—搬运路径—放置区”的相对位置固定下来。一个小场地加上几个标准纸盒就能把任务闭环跑起来。4. 整体方案设计4.1 系统架构蚂蚁搬家的系统可以拆成三层感知层摄像头采集图像识别物块位置和场地边界。决策层根据当前任务状态决定下一步动作。执行层驱动电机前进/转向控制机械爪开合释放或抓取物块。文字架构图如下感知层摄像头 → 图像预处理 → 目标识别 → 坐标输出 决策层状态机 → 任务队列 → 运动规划 → 指令下发 执行层电机驱动 → 运动控制 → 搬运机构 → 动作完成反馈这个结构特别适合个人备赛。每一层都可以单独测试摄像头拍到物块之后先在电脑上验证识别逻辑运动控制单独跑一段直线验证编码器和 PID 是否正常机械爪单独测试开合角度。最后再合并进行闭环测试。4.2 模块划分个人备赛必须有一个模块清单否则很容易陷入“今天调摄像头明天又回去改机械”的混乱状态。我把项目分成四个模块视觉模块负责图像采集、物块检测、坐标转换。控制模块负责电机速度闭环、转向控制、定点停车。执行模块负责机械爪动作、舵机角度控制。调度模块负责整个任务流程状态切换比如“待机→寻找物块→接近→抓取→运输→放置→复位”。每个模块对应一个代码文件接口提前约定好。比如视觉模块输出“物块中心在图像中的像素坐标”控制模块根据这个坐标调整车头方向。这样调试起来不需要在全局代码里翻来翻去。5. 核心技术点拆解5.1 视觉识别物块定位蚂蚁搬家最核心的感知任务是找到物块在哪。大一阶段不推荐直接上深度学习模型一方面训练数据量不够另一方面嵌入式平台跑模型会带来额外延时。更稳的方案是传统图像处理采集图像后将 RGB 转换到 HSV 颜色空间。设置目标颜色的阈值范围生成二值化图像。使用轮廓检测找到物块区域。计算轮廓的中心坐标和大小。HSV 比 RGB 更容易适应光照变化。调试时先用一张静态图片确定阈值再用摄像头实时阈值查看效果。import cv2 import numpy as np cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: break hsv cv2.cvtColor(frame, cv2.COLOR_BGR2HSV) # 示例阈值需要根据实际物块颜色标定 lower np.array([20, 80, 80]) upper np.array([35, 255, 255]) mask cv2.inRange(hsv, lower, upper) contours, _ cv2.findContours(mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) for cnt in contours: area cv2.contourArea(cnt) if area 1000: x, y, w, h cv2.boundingRect(cnt) center (x w // 2, y h // 2) cv2.circle(frame, center, 5, (0, 0, 255), -1) cv2.imshow(frame, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码可以在电脑上先用图片或者摄像头验证识别逻辑。确认目标颜色能稳定提取后再移植到单片机或者与主控配合的视觉模块上。5.2 运动控制定点停车与转向蚂蚁搬家的运动控制比纯竞速更难因为最后要停在物块旁边并且位置精度直接影响夹爪能不能对准。基础方案是双闭环速度环通过编码器读取实时速度PID 调节 PWM 占空比。位置环通过累计编码器脉冲数估算行驶距离接近目标时减速停车。转向控制可以用比例控制根据视觉模块输出的物块横坐标与图像中心线的偏差换算成转向舵机角度。// 伪代码示例实际参数需要根据车模和电机标定 int position_error target_x - image_center_x; int steering_angle base_angle kp_steer * position_error; if (position_error 0) { // 物块偏右向右转向 set_servo_angle(steering_angle); } else { // 物块偏左向左转向 set_servo_angle(steering_angle); }大一阶段最容易犯的错是 PID 参数一次调太大车直接在原地震荡。正确做法是先测出电机的最小启动 PWM再逐步加大比例系数每次只改一个参数。5.3 搬运机构抓取与释放机械爪的设计决定了搬运成功率。如果机械爪机构太复杂大一一个人很难在两周内调稳。我最初选的是带舵机的两指夹爪后面根据物块材质换过电磁铁方案。抓取逻辑不能只看机械结构还要考虑“抓没抓到”的反馈。最简单的方式是加一个限位开关或者反射式光电传感器检测夹爪之间是否有物块。流程大概是视觉定位到物块。车体向前缓慢接近。到达抓取位置后夹爪闭合。传感器确认夹到物块。提升或转向进入搬运状态。到达放置区后夹爪释放。这个流程里每一步都要有超时保护。比如夹爪闭合后 2 秒内传感器没有触发就退出抓取状态重新规划。个人备赛时超时保护能防止车卡在一个错误动作里方便后续定位问题。5.4 任务调度状态机蚂蚁搬家的任务不是一条直线跑完中间有分支。状态机是最直观的调度方式。用 C 语言定义状态枚举typedef enum { STATE_IDLE, STATE_SEARCH, STATE_APPROACH, STATE_GRAB, STATE_CARRY, STATE_PLACE, STATE_RETURN, STATE_DONE } TaskState;每次主循环根据当前状态执行对应函数然后判断切换条件。比如STATE_SEARCH 状态下视觉模块若返回物块坐标切换为 STATE_APPROACH。STATE_GRAB 状态下传感器检测到物块切换为 STATE_CARRY。STATE_CARRY 状态下到达放置区坐标切换为 STATE_PLACE。状态机写起来不难难的是状态切换条件要清晰。不要在一个状态函数里写超过 20 行逻辑否则后面改一个条件就可能引入隐藏 bug。6. 大一学生的备赛时间线个人备赛必须把时间切成阶段不然很容易前松后紧。第 1 到 2 月基础学习期。这个阶段不急着碰车先把 STM32 的基本外设过一遍GPIO、定时器、PWM、串口、外部中断。同时看往届智能车竞赛的公开技术报告和视频重点看别人怎么分工、怎么设计机械结构。第 3 到 4 月最小系统搭建期。把车模底盘、电机驱动、主控、电池接通让车能通过遥控或者简单串口指令前进后退。不要急着加摄像头先解决供电和电机控制的基础问题。很多大一项目死在这个阶段原因是电池接线不规范一给大电流主控就复位。第 5 到 6 月单项模块验证期。视觉模块先在电脑上跑通控制模块独立做直线测试机械爪单独测开合。每个模块各自验证完成后再开始拼接。如果在这个阶段发现摄像头帧率不够或者电机响应太慢还有时间换方案。暑假前一个月联调期。这个阶段重点是跑通完整任务闭环。第一次联调不要追求一次成功先让车能“看到物块并走过去”再增加抓取、搬运、放置。赛季最后两周稳定性优化期。停止大改方案只做参数微调。每天记录跑车成绩统计成功率。这个时候最容易发现的问题往往是供电不稳、接线松动、阈值漂移而不是逻辑错误。7. 功能测试与效果验证7.1 视觉识别单项测试测试目的确认摄像头能稳定识别目标物块。操作方式固定摄像头摆放物块在不同位置。运行图像识别脚本输出物块中心坐标。记录不同光照条件下的识别成功率。判断标准连续 50 帧图像中检测成功率不低于 90%。如果低于这个值先调阈值再看是否需要用白平衡或自动曝光。失败排查方向物块颜色与背景太接近选择与场地反差更大的目标物。光线变化导致阈值失效增加 RGB 或 HSV 范围。摄像头曝光太强物块边缘过曝降低曝光时间。7.2 运动控制单项测试测试目的确认车辆能准确从起点行驶到目标位置。操作方式在场地地面标记起点和终点。编写程序让车从起点加速到设定速度再在终点前减速停车。记录实际停车位置与目标位置的误差。判断标准平地上停车误差控制在 2 到 3 厘米以内。如果误差偏大检查编码器安装是否牢固、轮胎是否打滑、PID 参数是否合理。失败排查方向编码器数据抖动检查接口接触。电机 PWM 死区导致低速时不可控增加最小占空比。电池电压下降导致速度环输出不够需要加入电压补偿逻辑。7.3 完整任务联调测试目的验证“识别—接近—抓取—搬运—放置”全流程。操作方式在场地固定位置放一个物块。车从起点出发完成一次完整搬运。记录从启动到完成用时以及是否成功。这个阶段我给每个环节加了单独的串口日志比如[STATE] SEARCH [STATE] APPROACH [STATE] GRAB [SENSOR] GRAB_OK [STATE] CARRY [STATE] PLACE [STATE] DONE日志能帮你快速定位是哪一步出了问题。第一次跑通全流程时不要追求速度先把成功率做到 80%再逐步压缩单次任务时间。失败排查方向如果倒在第 1 步优先检查摄像头安装角度和物块颜色阈值。如果倒在抓取阶段检查夹爪行程和舵机扭矩。如果倒在放置阶段检查坐标换算或车体定位累计误差。8. 个人备赛常见问题与排查方法个人备赛最怕的是问题定位慢。这里整理一份高频问题清单问题现象可能原因排查方式解决方案上电后主控反复重启电源供电不足或电池接线松动万用表测量各模块供电电压电机驱动单独供电主控使用独立稳压模块摄像头图像白屏或花屏数据线接触不良或供电不稳换线测试检查摄像头电压使用屏蔽线缩短数据线长度车走不直两侧电机转速不一致编码器读取左右轮速对比给两侧电机分别标定做速度闭环PID 参数一调就飞比例系数过大或限幅缺失减小 P观察车体响应先只调 P再加 D每次只改一个参数物块识别不稳定光照变化导致阈值失效打印实时 HSV 值增加自适应阈值或固定摄像头曝光机械爪夹不到物块夹爪行程不足或位置偏移手动测试夹爪开合范围调整安装位置增加导向结构任务跑一半卡住状态机状态切换条件不满足查看串口日志最后一条状态增加超时退出机制所有状态增加超时跳转联调次数多了性能下降电池电压下降检查空载和负载电压差准备多块电池轮换使用这些问题的共同点是需要先把“模块边界”画清楚。一个人调试时如果串口日志能定位到是图像处理慢了还是电机响应慢了问题就解决了一半。9. 工程化管理与个人效率提升一个人干三个人的活不是靠堆时间而是靠规范。第一用 Git 管理代码。哪怕只有一个人Git 也很重要。我经常在“改了一下阈值之后车就完全跑不了”的情况下靠 git checkout 回到上一个能跑的版本。建议每次完成一个单项测试就提交一次提交信息写清楚改动内容。git add . git commit -m feat: add grab position feedback sensor第二写调试日志。不要只在代码里 printf日志要有格式要能直接看出当前状态和关键传感器值。我用最简单的方式串口每 100ms 输出一行T100ms V_L1.2m/s V_R1.3m/s STATEAPPROACH TARGET_X128有了日志赛后复盘不用靠记忆直接看文件就行。第三对机械结构做配置记录。很多人只调代码忽略了机械参数。比如舵机安装角度偏差、夹爪初始开度、摄像头俯仰角这些都是影响代码的参数。我给每一项建了一个配置文件每次改动都记录原因和结果。第四做好时间记录和任务拆分。个人备赛很怕进入“感觉在忙但不知道忙什么”的状态。我把每周目标拆成可以验证的小任务比如“这周完成 HSV 阈值标定”而不是“这周搞视觉”。完成一个就划掉一个会更有掌控感。10. 从备赛记录看智能车竞赛的公开资料利用智能车竞赛的信息量很大每年规则、技术报告、国赛名单发布之后都需要自己去消化。备赛期间我重点关注三类公开资料。第一类是官方技术文件。包括比赛规则、车模技术参数、传感器允许列表。这些是方案的边界条件必须逐条看。第二类是往届参赛队伍的技术报告。很多队伍会把机械结构图、控制框架、调参经验写得很详细。一个人备赛时看报告相当于让几十个团队帮你提前踩坑。第三类是像卓晴老师这类竞赛指导者分享的规则解读和调试视频。尤其是规则变化较大的年份这类内容能帮你快速抓住重点避免把精力浪费在不会被考核的技术点上。有一点要提醒公开资料里经常会有不同队伍之间的方案差异不要盲目照搬。比如有人用高算力视觉模块有人坚持低成本 MCU 方案你要结合自己的预算和时间选择一条能跑通的路。11. 个人备赛最值得尝试的点与未来方向如果让我重新选一次我仍然会在大一选蚂蚁搬家。原因不是它容易获奖而是它能逼着你把“一个功能从想法变成实物”的路走一遍。这个过程里学到的内容比单纯刷题要立体得多写代码要考虑实时性做机械要考虑安装公差联调时要学会从现象反推根因。对一个刚进大学的学生来说最先应该验证的功能不是高难度的视觉算法而是“能不能让车按照指令稳定走起来并且在不同状态下正确切换”。把这条闭环跑通蚂蚁搬家就已经建立了最低可用版本。之后再去优化视觉识别准确率、提高搬运速度都是增量工作。最容易踩的坑一个是前期方案调研不足导致中后期大改另一个是硬件和软件没有分开调试一上来就联调出了问题分不清是谁的锅。这两种坑对个人备赛来说都消耗很大。后续如果继续深入可以往嵌入式实时系统、运动控制算法、机器视觉应用这三个方向延伸。不一定继续做竞赛但备赛期间建立的那套“模块化设计—单项验证—系统联调—数据复盘”的方法论在任何硬件相关项目里都通用。蚂蚁搬家这个名字很形象小蚂蚁搬走比自身体积更大的东西靠的是耐心和拆解能力。大一一个人备赛本质上也是在练这件事。