当我在大一一个人选择了蚂蚁搬家连实验室学长听到后的第一句话都是“你自己能调得完吗”那时候我只知道蚂蚁搬家组要抓东西要搬东西车要自己走至于怎么让车认识目标、怎么把机械臂稳定落到抓取点上、怎么在赛场上不出岔子全是一头雾水。一个学期走完之后回头看一个人备赛最难的从来不是某个算法而是所有环节都要自己闭环机械装错要自己拆电路不通要自己量视觉识别不上要自己调比赛前一天车突然不走了也只能自己抢修。蚂蚁搬家组是智能车竞赛里非常典型的综合赛项。它不追求极致的竞速圈速而是要求小车在场地中完成“识别目标、规划路径、抓取物体、搬运到位”这一整套动作。相比纯竞速组它多了一套视觉与机械臂配合的控制链路相比纯创意组它又必须落地到固定的比赛任务上。一个人选择这个组实际上是把机械、电路、嵌入式、视觉、控制、策略六条线全部压在自己身上。这篇文章不按获奖经验来写就按备赛记录来写蚂蚁搬家组需要什么能力、一个人怎么准备环境、工程怎么搭、测试怎么排、问题怎么查、比赛当天怎么稳住。如果你正在考虑报蚂蚁搬家组或者已经报了但不知道从哪下手可以先看下面的能力速览再对照自己的备赛周期做取舍。1. 蚂蚁搬家组赛项与核心能力速览能力项说明赛项类型智能车竞赛综合任务类常见任务包含识别、抓取、搬运、放置典型控制对象车模运动控制、转向舵机、机械臂关节舵机、抓取机构感知输入摄像头视觉为主常见方案为色块识别、目标定位、面积/坐标输出决策核心主控 MCU 或嵌入式 Linux 板卡负责状态机调度与执行逻辑运动控制电机速度闭环、舵机转向控制常配合 PID 类算法机械结构机械臂、夹爪或吸盘需考虑运动范围和负载能力比赛目标从起点出发找到指定目标物体抓取并搬运到规定区域单人备赛难点机械与软件互相依赖调试需要来回切换时间管理压力大更适合的学习基础有一定 C/C 编程基础了解基本电路连接愿意动手拆装从表里可以看出蚂蚁搬家组最核心的不是单一技能而是“感知到执行”的闭环能力。一个人备赛的时候最容易出现的情况是视觉模块单独跑很好机械臂单独动也很顺但一旦把两者接起来车就不知道先看哪里、先动哪里。所以整个备赛过程的核心任务就是不断缩小“每个模块单独能用”和“整车上电能跑完整流程”之间的差距。2. 适用人群与单人备赛边界蚂蚁搬家组适合动手能力比较均衡的人。如果你更擅长软件会在这里被迫补上机械和电路的知识如果你更擅长硬件也会被视觉和状态机调度推着学编程。这种“被迫全面”对大一学生来说其实是好事但也要提前知道代价。一个人备赛时以下几类情况会比较吃力备赛周期严重不足。机械组装、视觉调试、整车联调都需要时间单人操作效率天然低于团队分工如果只剩两三周不建议硬选这个组。完全没有任何硬件经验同时不愿意动手拆装。智能车不是写一个程序就能跑的东西螺丝松了、杜邦线接触不良、舵机扫齿、电池电压不足都是日常问题。赛道和规则理解不清楚。蚂蚁搬家组通常有明确的场地元素和任务要求如果不去研究往届规则和技术文档很容易把时间花在错误的方向上。但反过来如果你有一颗“拆了能装回来”的心态一个人也能推进。我的经验是把任务拆成三层机械层车模组装、摄像头支架固定、机械臂安装。这一层尽量一次性做稳避免后期频繁返工。电气层电池、降压模块、主控、电机驱动、舵机供电、视觉模块供电。先画连接图再接线不要一边想一边插。软件层主控程序、视觉程序、状态机逻辑、参数调整。这一层是后期迭代最多的部分需要预留整块时间。一个人备赛的时间和精力都有限所以边界要清晰优先保证把“一辆能稳定跑完一遍任务的车”做出来再去追求性能和速度。摄像头支架松动导致识别漂移比算法参数没调好更可怕因为前者你往往看不出来等到赛场上才爆发。3. 备赛环境与硬件准备3.1 软件环境蚂蚁搬家组的软件调试主要集中在两个部分主控程序开发和视觉模块开发。以常见的 MCU 方案为例需要准备工具用途备注Keil / IAR / VS Code 等 IDE编写和编译主控程序具体以主控型号对应的官方工具链为准串口调试助手查看主控打印的日志建议支持多窗口方便同时看不同设备输出视觉模块配套 IDE调试摄像头识别参数比如色块阈值、曝光、分辨率图像查看/录像工具保存现场图像复盘识别问题可以用手机拍摄屏幕正规一点可用截图或录像如果视觉部分使用 OpenMV、K210、树莓派等平台一般都有各自的开发环境。无论用哪一种建议把“帧率、分辨率、识别区域、输出数据格式”记录在工程注释里方便后续排查。3.2 硬件清单不同学校、不同赛区的设备资源差异很大这里给的是通用分类不写死具体型号车模平台四轮或两轮车模包含底盘、电机、轮胎、电池仓。主控板常见 MCU 开发板或带摄像头接口的嵌入式板卡。摄像头模块用于采集赛道和目标物体图像。电机驱动模块驱动直流电机或带编码器的电机。舵机用于转向和机械臂关节控制。机械臂套件或自制结构件包括支架、夹爪、舵机云台、螺丝螺母。电源系统电池、降压模块、分电板、开关。调试工具万用表、螺丝刀套装、杜邦线、扎带、热缩管、电烙铁。单独强调一下电源。蚂蚁搬家组比纯竞速组多了一路机械臂舵机舵机启动瞬间电流可能很大如果供电设计不好会导致主控复位或者摄像头画面闪黑。常见做法是让主控、摄像头、舵机分开取电或者至少确保电源模块的峰值电流足够。最简单有效的检查方式是让机械臂连续动作的同时观察主控是否重启、舵机是否抖动。3.3 环境检查清单上电之前先花十分钟做静态检查能省掉很多“车莫名其妙不动”的排查时间电池电压是否在正常范围内。电源正负极是否接反开关是否接在电源主回路上。主控与电机驱动共地是否接好。舵机信号线是否插到正确引脚供电方向是否正确。摄像头排线是否插紧镜头上是否有保护膜。机械臂螺丝是否拧紧夹爪开合是否顺畅。各模块之间是否留有足够空间避免运动时刮线。4. 工程搭建与启动流程4.1 整体架构感知-决策-执行蚂蚁搬家组整车程序从高到低可以分成三层感知层摄像头识别目标物体输出物体坐标、面积、颜色信息。决策层状态机根据当前状态和感知信息决定下一步动作。执行层控制电机速度、舵机转向、机械臂关节角度和夹爪开合。这三层对应到代码上一般是视觉模块单独跑一个程序主控跑一个程序两者通过串口或 I2C 通信。这里给出一个主控状态机设计的示意代码typedef enum { STATE_IDLE, // 待机 STATE_SEARCH, // 搜索目标 STATE_APPROACH, // 接近目标 STATE_GRAB, // 抓取 STATE_CARRY, // 搬运 STATE_PLACE, // 放置 STATE_BACK, // 返回 STATE_FINISH // 结束 } task_state_t;通常不建议把所有逻辑堆在中断里。更稳的方案是主循环里跑状态机定时中断里做速度控制串口接收回调只负责把视觉数据缓存起来等主循环统一处理。4.2 主控工程初始化配置下面以 STM32 HAL 库为例给出一个工程初始化框架。注意这里只是结构示意具体引脚、时钟、外设配置需要按你的开发板修改。void System_Init(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_DMA_Init(); MX_UART_Init(); // 与视觉模块通信 MX_TIM_Init(); // 舵机 PWM 输出 MX_ADC_Init(); // 电池电压检测 MX_ENCODER_Init();// 电机编码器输入 }初始化完成后建议先写一个简单的自检程序逐一测试外设串口是否接收到视觉模块数据、PWM 能否控制舵机角度、编码器读数是否随车轮转动变化。自检通过后再加入控制逻辑这样后期定位问题会容易很多。4.3 上电自检流程一个人备赛时上电自检尽量按照固定流程来不要每次自由发挥先不装机械臂只给主控和视觉模块上电确认主控启动信息正常输出。再给电机驱动上电空转测试左右电机方向确认前进、后退、转向对应关系。接着接上转向舵机用手扶着车轮确认左右打角方向和程序指令一致。最后接机械臂和夹爪测试关节转动方向和夹爪开合状态。全部正常后再开始整车联调。判断自检是否成功的标准很简单主控能稳定输出日志视觉模块能持续发送有效数据帧舵机响应无抖动电机方向正确机械臂动作到位。5. 功能测试与效果验证5.1 循迹与行进测试测试目的确认小车能按照赛道元素稳定行进不会反复蛇形或冲出赛道。输入素材一段独立铺好的赛道起点和终点清晰。操作步骤将摄像头固定在车头调整俯仰角让视野能看到正前方约 20 到 40 厘米的赛道。编写一个最简单的巡线或直行程序让车沿赛道中线前进。观察小车在直线、弯道、交叉口处的表现。预期结果小车能保持在中线附近弯道不剧烈抖动直道不左右偏摆。判断成功标准连续跑完五圈不发生冲出赛道或原地转圈。常见失败原因摄像头曝光过高、阈值取错、车模机械左右不对称、PID 参数过冲。5.2 目标颜色识别测试测试目的确认摄像头能稳定识别目标物体的颜色和位置。输入素材比赛同色的小块物体放在不同距离和不同光照位置。操作步骤固定摄像头阈值让物体进入画面。观察识别框是否稳定跟随物体。记录不同距离下中心坐标和面积的变化。预期结果物体在画面中时视觉模块能持续输出目标坐标物体移出画面时输出“未识别到目标”的状态。判断成功标准同一物体在 30 厘米、50 厘米、80 厘米距离下识别率保持稳定坐标跳变不明显。常见失败原因环境光变化导致阈值失效、物体颜色与赛道元素太接近、摄像头白平衡自动漂移。5.3 抓取机构测试测试目的确认机械臂能稳定完成“对准-下压-抓取-抬起”动作。输入素材与比赛物体大小接近的道具放置在小车前方固定位置。操作步骤让车停在物体前方使用视觉坐标或位置开关让机械臂对准物体。记录舵机从初始角度到抓取角度的动作时间。抓取后尝试保持物体 3 秒以上确认夹持稳定。预期结果机械臂动作平滑夹爪能夹紧物体抬起后物体不掉落。判断成功标准连续抓取十次成功八次以上。常见失败原因机械臂关节行程不足、舵机扭力不够、夹爪行程与物体尺寸不匹配。5.4 完整搬运流程测试测试目的验证从起始区出发、识别目标、抓取、搬运、放置的完整流程。输入素材完整场地布置目标物体放在指定位置放置区可用标记线标识。操作步骤将车放到起点使用统一供电执行完整任务程序。记录整趟任务耗时以及每一步是否顺利切换状态。观察失败点在哪个状态搜索不到、接近撞车、抓取失败还是放置偏差过大。预期结果小车能完成完整流程状态机切换顺序正确。判断成功标准连续完成三次完整任务至少两次完全成功。常见失败原因状态机缺少超时保护某一步卡住后整个流程死等视觉坐标与机械臂坐标没有标定对齐放置点判定过于简单。6. 单人调试管理与批量参数记录一个人备赛最常见的问题不是车不行而是“上午还行下午就不行了”但你不知道改过什么。所以参数管理和日志记录极其重要。6.1 参数表建议整理一份参数表记录每个摄像头阈值、PID 参数、舵机中值、电机速度等关键参数。可以简单地用一个 Markdown 表格维护在工程目录下参数名称数值调整日期当时场地条件备注红色物体 L 阈值252025-XX-XX室内灯光距离 50 cm循迹 P0.352025-XX-XX新赛道弯道略抖舵机中值902025-XX-XX安装后标定需要微调6.2 日志与录像主控串口日志建议统一格式方便脚本后期统计。例如[LOG] stateAPPROACH img_x120 img_y80 area5000 voltage7.4 [LOG] stateGRAB servo_arm55 servo_grab20 [LOG] stateCARRY speed_left1200 speed_right1150在调试摄像头时录像比截图更直观。很多偶发问题只会在连续运动中暴露比如物体在某一帧突然丢失需要回头在录像里看是曝光问题还是遮挡问题。6.3 批量测试用例设计一个人备赛时建议把“测试”也当作代码来管理。每个测试用例固定包含前置条件、操作步骤、预期结果、判断标准。用例编号名称前置条件操作步骤预期结果T01串口通信主控与视觉模块上电发送握手帧收到应答T02动态识别物体在 40 cm 处移动物体坐标连续跟踪T03抓取稳定性机械臂标定完成连续抓取 10 次成功率 ≥ 80%T04完整流程场地布置完成整车执行任务状态机按时序完成批量测试的重点是“可复现”同一套用例在不同版本代码上跑能快速看出这次改动是否引入了回归问题。这对单人开发尤其重要因为没有人会替你记代码改动前的行为。7. 资源占用与性能观察蚂蚁搬家组虽然不需要像电脑上跑深度学习那样看显存但同样存在“资源占用”问题主要观察这几个维度。摄像头帧率帧率太低会导致运动过程中物体丢失。常见做法是降低分辨率或用灰度图提升帧率具体能否满足取决于识别距离和车速。主控 CPU 占用如果主控任务过重状态机的运行频率会不稳定可能出现舵机响应变慢、电机控制不平滑。排查方法是增加一个任务调度占空比打印看主循环周期是否稳定。舵机电流与电压跌落机械臂动作瞬间电流很大这时如果电池电压跌落明显摄像头可能会黑屏或者主控复位。用万用表或 ADC 监测电压是比较有效的办法。电机转速反馈编码器数据可以反映实际速度和目标速度的偏差如果偏差持续偏大说明电机驱动能力或电池供电不足。观察方法可以在主循环里做一次统一采集把状态和时间戳通过串口输出printf([PERF] loop_time%d ms state%d vbat%.2f\r\n, loop_time_ms, state, vbat);如果发现 loop_time 不稳定优先检查是否在中断里做了耗时操作比如把图像处理放在主控中断里或者使用了阻塞式串口接收。更好的做法是把耗时任务放到状态机的某个分支里避免阻塞循环。8. 常见问题与排查方法问题现象可能原因排查方式解决方案上电后主控无反应供电不足、开关接触不良、程序未烧录检查电源电压、指示灯、下载器状态重新烧录确认电源连接摄像头画面闪黑电源跌落、排线松动、曝光异常观察机械臂动作瞬间画面是否变黑分离电源或更换低内阻电池识别目标不稳定光线变化、阈值错误、物体反光保存现场图像对比阈值调整曝光和阈值增加光照稳定措施舵机抖动供电电流不足、信号线干扰、舵机本身问题单独供电测试换舵机信号线增强电源滤波更换可靠舵机电机方向不一致电机接线极性错误、驱动逻辑错误空转测试左右电机方向调整接线或软件方向状态机卡住缺少超时保护、视觉数据一直无效串口打印当前状态给每个状态增加超时跳转抓取位置偏移视觉坐标与机械臂坐标未标定固定目标物体比对抓取点做机械臂坐标系标定加入偏移补偿放置位置偏差停止位置不准、机械臂回程误差录像观察放置点增加二次定位或减速缓冲一个人调试时最容易忽略的是“不要在场地里反复改参数”。正确做法是发现问题后先把车停到维修区通过日志和录像确认原因再一次性修改并验证。不然很可能会把阈值、PID 和机械位置一起越调越乱。9. 赛场应变与最佳实践9.1 赛前清单比赛前一天不要想着再改一个新功能而是把所有已验证过的配置固化下来主控程序、视觉模块程序和参数表各备份一份存到 U 盘和网盘各一份。备好电池充满电并检查电压。检查车模螺丝、机械臂关节、夹爪是否松动。多带一套备用螺丝、杜邦线、扎带、胶带和常用工具。确认比赛当天需要使用的场地元素是否和练习时一致。9.2 比赛现场调试顺序现场环境经常和实验室不一致尤其是灯光。到现场后先做固定流程上电自检确认主控、视觉、舵机、电机都能正常响应。重新检查摄像头曝光和颜色阈值因为现场灯光可能完全不同。用真实场地物体跑几次识别测试确认坐标稳定。在正式比赛之前至少完整跑一遍任务流程哪怕故意放慢速度。如果比赛中出现问题第一时间记录现场现象不要在地库反复试车。完成一轮比赛后利用候场时间确认问题原因再决定是否调整参数。9.3 规则与合规提醒备赛过程中有几条边界一定要守住借用和参考往届代码、开源项目时注意保留原作者的许可证声明按开源协议要求使用。个人学习备赛范围内问题不大但如果之后把代码开源或用于公开分享需要确认授权。摄像头和图像处理过程不要拍摄无关人员避免肖像权问题。比赛场地内按赛事规定使用摄像头即可。使用锂电池时注意充电安全充电时不要离开人。车上供电线路要固定好防止比赛过程中短路。比赛规则会逐年调整以当届官方规则为准。网上看到的往年经验可以借鉴但不能套用到规则不同的新赛道上。10. 总结与下一步一个人备赛蚂蚁搬家组最值得做的事情是尽早搭建“能跑的完整流程”哪怕每一步都很慢。先让车走起来再让车认识物体最后让机械臂把物体搬到位。这个顺序不能反。几乎所有中期崩溃的备赛经历都是因为太早追求某一个环节的完美忽略了整条链路的打通。最先应该验证的功能是摄像头识别和目标追踪因为视觉一旦不稳定后续所有抓取和搬运逻辑都建立在沙地上。最容易踩的坑是电源问题机械臂一动作主控就重启这种问题排查起来非常费时间不如一开始就把供电设计好。对于大一阶段来说选择一个人蚂蚁搬家其实不是选了一个赛项而是选了一次完整的工程实践。你能接触到的远不止 PID 和串口通信还有机械公差、电池放电、状态机设计、现场排障这些课堂上很难一次讲透的东西。下一步可以做的事情很多把视觉方案换成更统一的彩色检测流程给机械臂加上力或行程反馈把状态机改成可配置的数据驱动结构或者把整车日志接入上位机做离线分析。方向很多关键是先把第一版完整任务跑通再考虑怎么做得更漂亮。