参加 2026 VEX 机器人竞赛北京选拔赛的团队,通常会在赛前两三个月进入高强度备赛阶段。很多人以为比赛比的只是机器人跑得快、动作帅,真正到现场后会发现,决定名次的往往不是外观,而是结构是否稳定、自动程序能否复现、现场调试是否高效,以及突发故障时团队成员能不能快速定位问题。
这篇内容围绕从备赛到参赛的全流程来展开。把赛题拆成分数任务、设计机器人机构、编写和调试 VEX 程序、用训练赛数据复盘策略、整理比赛现场装箱与排障清单,每一段都按实际工程项目的方式处理。目标是让团队在去北京选拔赛之前,不只有一台能动的机器人,还有一套可复现、可检查、可回滚的备赛体系。
1. 先理解 VEX 机器人竞赛的工程结构
1.1 VEX 竞赛到底在考什么
VEX 机器人竞赛不是简单的“谁力气大谁赢”。每一年的赛题会有明确的场地任务,比如把某些积分物推入得分区、把圆环挂到目标杆上、和另一支队伍合作完成联动任务,或者比赛结束后把机器人停进指定区域。比赛阶段通常分为自动阶段和操作手控制阶段,自动阶段考验程序对场地误差和传感器数据的处理能力,操作手控制阶段考验操控熟练度、策略选择和临场配合。
对一个参加北京选拔赛的队伍来说,这意味着不能只把精力放在机械结构或者只写代码。比赛成绩由多个环节共同决定:机器人能否稳定完成基础得分、自动程序能否在每场比赛中重复同样路线、联队配合时能不能快速判断当前局势、故障出现后裁判允许的解决时间内能不能恢复。
1.2 从“会搭机器人”到“能稳定赢分”
很多队伍在训练时能跑出不错的分值,但一到比赛现场成绩就波动很大。原因通常不是某个零件坏了,而是整个团队的工程流程存在缺口:
- 结构没有做防松处理,几次比赛后螺丝松动,机构精度下降。
- 自动程序依赖固定时间和固定距离,场地摩擦、电池电压变化后结果偏差大。
- 只练了“最理想路线”,没有准备备用路线,联队对手打法一变就不知所措。
- 没有做版本管理,现场改了程序后发现性能变差,却回不到之前稳定的版本。
所以备赛的核心思路应该是:先保证基础功能稳定,再追求高分路线;先让程序和结构“可预测”,再谈临场发挥。
2. 备赛第一步不是画图,而是把赛题拆成分数任务
2.1 拆解得分任务
拿到当赛季官方规则手册后,先不要急着设计机器。队内所有成员要对赛题形成统一理解。建议用一张大白纸记录以下信息:
- 场地尺寸和区域划分。
- 积分物种类、初始位置、大小和重量。
- 每种得分方式对应的分值。
- 自动阶段有哪些特殊加分规则。
- 罚分规则,比如越线、破坏场地、超时操作。
- 联队配合规则,哪些任务需要两名操作手共同完成。
拆解之后,把任务按“固定得分”“高分区任务”“高风险任务”分类。固定得分指不依赖对手、不依赖高难度操作就能拿到的分数,比如比赛一开始规规矩矩把一个积分物推进低分区。高分区任务分值高,但要求结构、程序、操控都达到较高水平。高风险任务往往用来打最后一搏,比如最后几秒放置一个高价值物品,成则翻盘,失败则可能浪费时间甚至罚分。
2.2 将任务映射到机器人功能模块
每一项得分任务都必须落到机器人的具体功能模块上。用表格整理会比较清晰:
| 赛题任务 | 需要的机构功能 | 对应模块 | 难度评估 |
|---|---|---|---|
| 快速获得低分区基础分 | 把积分物推进目标区 | 底盘、推挡板 | 低 |
| 获得高分区积分 | 抓取并高空放置积分物 | 升降机构、末端抓取器 | 高 |
| 自动阶段完成固定路线 | 按程序行驶到指定坐标 | 底盘、传感器 | 中 |
| 联队配合转移积分物 | 接收、传递积分物 | 取物机构、通道结构 | 中 |
| 比赛结束机器人回到基地 | 精确停位 | 惯性传感器、编码器 | 中 |
这张表的价值在于,它能让团队确认:哪些功能是比赛必须有的,哪些功能是因为“看着炫”才想加的。北京选拔赛的备赛时间有限,优先保证基础分和高频得分点,不要把精力全部压在难度最大、风险最高的动作上。
2.3 可行性评估与取舍
到了取舍阶段,要问三个问题:
- 这个功能在剩下来的备赛时间内能真的稳定吗?
- 即使不稳定,它是否有替代方案可以保住大部分分值?
- 如果取消,省下来的电机口、结构空间和调试时间能不能贡献到别的高分任务?
一个典型例子是:团队想做一个复杂的四杆升降机构,用于把积分物放到最高分区域,但因为结构重心过高,机器人转弯就会晃。此时更合理的做法是先做一辆低重心、带稳固取物装置的机器,保证中低分区稳定得分,再根据进度决定要不要升级升降机构。
3. 机器人机构设计:用最少零件做最稳定的功能
3.1 底盘与驱动设计
底盘是所有动作的基础。VEX V5 的电机扭矩充裕,但底盘设计不合理时,会出现起步顿挫、转弯扫尾、上坡打滑等问题。常见做法是选择合适的传动比:需要速度快时用高速齿轮比,需要扭矩搬运重物时用大减速比。队内最好记录每种传动比下的实际表现,而不是只看理论速度。
底盘还要考虑重心。比赛机器人加速、急停、转弯时,重心偏高容易翻车,重心靠前则可能导致底盘前倾。经验是尽量把电池、主控器等较重的部件放在中后部低处,避免把重量全部堆在升降机构附近。
3.2 取物与放置机构
取物机构的形式取决于赛题,通常有推板、夹爪、抬升臂、滚筒输送等。选择时先问清楚:
- 积分物是什么形态,规则允许怎样接触它。
- 抓取后是否需要保持固定,还是只需要推动。
- 机构在自动阶段和手动阶段是否共用同一套动作。
如果是第一次参加比赛,推荐先做“容错率高的机构”。比如用宽推板而不是精密切爪,因为宽推板可以容忍操作手的一点偏差,而窄夹爪差一厘米就可能夹空。
3.3 结构刚性的三个常见坑
第一,只用尼龙轴套和金属轴配合时,如果零件间隙过大,机构在负载下会出现明显晃动。解决方式是在关键轴上加轴承固定,减少轴向窜动。
第二,铝型材切好后不处理毛边,装配时不仅容易划手,还会导致螺丝拧不紧。装配前花几分钟倒角清理,能减少后续大量返工。
第三,大量使用长螺丝直接穿过多个结构件,而没有加支撑,负载后连接处会变形。建议在受力方向上加金属角码或额外固定板,让力不从单颗螺丝上传递。
结构设计完成后,还要考虑“检修友好度”。如果某个电机需要拆掉半个底盘才能更换,比赛现场基本等于报废。合理做法是让电池、主控器、主电机保持快速拆卸,现场的每一秒都很贵。
4. VEX 编程与自动程序调试:从传感器读到闭环控制
4.1 开发环境与程序结构
VEX V5 常用的编程开发环境是 VEXcode V5 和 VEXcode Pro V5。前者适合图形化编程快速验证逻辑,后者适合 C++ 或 Python 工程化开发。建议队伍在初期就统一开发环境,并确认一下当前安装的 VEXcode 版本与主控器固件版本是否匹配。
程序结构上,不要把所有逻辑都堆在main函数里。常见工程化拆分如下:
robot-config.cpp:定义电机、传感器和控制器对象。autonomous.cpp:自动阶段路线函数。driver.cpp:操作手控制逻辑。util.cpp:通用工具,比如电机限速、传感器校准、屏幕显示。
这样在比赛中调整某个函数时,不会误改其他逻辑。
4.2 传感器读取检查程序
机器人要稳定走位,不能只靠电机转多久。建议在自动程序开发先写一个“传感器读数检查程序”,把各个传感器的实时数值打印到 V5 主控器的屏幕上。示例思路如下:
#include "vex.h" using namespace vex; motor LeftDrive(PORT1, ratio18_1, false); motor RightDrive(PORT10, ratio18_1, true); inertial Inertial(PORT5); optical ColorSensor(PORT6); int main() { Inertial.calibrate(); while (Inertial.isCalibrating()) { wait(20, msec); } while (true) { Brain.Screen.clearScreen(); Brain.Screen.setCursor(1, 1); Brain.Screen.print("Heading: %.1f", Inertial.heading()); Brain.Screen.setCursor(2, 1); Brain.Screen.print("Brightness: %d", ColorSensor.brightness()); Brain.Screen.setCursor(3, 1); Brain.Screen.print("Distance: %.1f mm", DistanceSensor.objectDistance(mm)); wait(100, msec); } }这段代码的目标是让队伍在装到场地后,第一时间确认惯性传感器校准是否完成、光学传感器是否受环境光影响、距离传感器能否稳定读值。如果训练场地和比赛场地的灯光条件不同,这类检查尤其重要。
4.3 自动程序从“固定路线”到“带反馈路线”
最简单的自动程序是:左轮前进 80% 速度,等待 1000 毫秒,停止,再让右电机单独前进,完成转弯。这种写法在空场地、满电量时没有问题,但积分物位置偏差、轮胎打滑、电池低电量都会让机器人偏离预期位置。
改进方向是加入传感器反馈。比如转弯时使用惯性传感器,当朝向角度到达目标值时停止:
#include "vex.h" using namespace vex; motor LeftMotor1(PORT1, ratio18_1, false); motor LeftMotor2(PORT2, ratio18_1, false); motor RightMotor1(PORT3, ratio18_1, true); motor RightMotor2(PORT4, ratio18_1, true); motor_group LeftDrive(LeftMotor1, LeftMotor2); motor_group RightDrive(RightMotor1, RightMotor2); inertial Inertial(PORT5); void turnTo(float targetHeading, int speed) { Inertial.setHeading(0, degrees); if (targetHeading > 0) { // 顺时针转:左轮前进,右轮后退 LeftDrive.spin(forward, speed, percent); RightDrive.spin(reverse, speed, percent); } else { LeftDrive.spin(reverse, speed, percent); RightDrive.spin(forward, speed, percent); } while (fabs(Inertial.heading() - targetHeading) > 2.0) { wait(10, msec); } LeftDrive.stop(); RightDrive.stop(); } int main() { Inertial.calibrate(); while (Inertial.isCalibrating()) { wait(20, msec); } turnTo(90, 50); }这只是示意代码,实际工程里还要根据电机方向、转向摩擦和齿轮比调整。核心思想是:用传感器闭环替代纯时间控制,让程序在电池电量变化后依然有较高重复性。
4.4 PID 调参的基本思路
当机器人需要保持直线、精确停车或悬停固定角度时,常见的做法是使用 PID 控制。PID 三个参数作用不同:
- P(比例):当前误差越大,输出越强。P 太小会没劲,P 太大会震荡。
- I(积分):消除长期累积的偏差,比如持续走偏。
- D(微分):抑制变化速度,减少超调。
调参时建议先只调 P,把机器人放在场地上,看它是否向目标方向移动、是否来回震荡。P 稳定后加入 D,用来减缓过冲。I 通常在机器人存在持续摩擦或负载时再引入。不要一开始就照抄其他队伍的 PID 参数,每一台机器人的重量、传动比和轮胎抓地力都不同。
调参过程中要注意:不要让电机持续卡死,否则电机电流过大,会触发 V5 电机的过流保护,表现为机器人突然失去动力。
5. 训练赛数据采集:用复盘代替感觉
5.1 每场训练都要记录,不只看比分
很多队伍的失败不是练得少,而是练完不总结。同样的路线反复跑,跑得顺了就觉得行了,跑歪了就说“刚才手抖了一下”。这种“感觉流”训练很难让机器人真正稳定。
建议每场训练都记录一份比赛数据表:
| 场次 | 自动阶段得分 | 手动阶段得分 | 总得分 | 故障点 | 故障原因 | 改进动作 |
|---|---|---|---|---|---|---|
| T01 | 12 | 20 | 32 | 自动阶段最后冲过头 | 惯性传感器未校准 | 启动前增加校准等待 |
| T02 | 12 | 18 | 30 | 取物夹爪松开时卡住 | 导轨间隙过大 | 更换轴承并加垫片 |
| T03 | 14 | 22 | 36 | 低电量时速度明显下降 | 电池电量低 | 更换满电电池再比 |
记录的价值在于:当比赛成绩出现波动时,能快速判断问题出在结构、程序还是操作,而不是三个人同时凭记忆找原因。
5.2 用数据判断路线冗余
自动阶段要设计“路线冗余”。意思是:即使在起点放偏 2 厘米、积分物位置偏差一点、电池不是满电,程序也应该能把核心任务的完成率保持在较高水平。
检验方法是做“抗干扰测试”。比如用同一套自动程序连续跑 10 次,每次故意把机器人起点偏移一点点,观察任务完成情况。如果 10 次里有 5 次失败,说明路线的容错率不够。此时不要急着加大 P 或调整速度,而是先检查机械结构是否松动、轮子是否磨损、视觉传感器阈值是否过窄。
5.3 训练-复盘-再验证的节奏
建议把备赛周期切分成多个小周期,每个小周期两端有明显验证点。比如周一改结构,周二写程序,周三做三轮测试,周四根据数据决定是否保留改动,周五再跑一次完整模拟。不要等到赛前最后一周才把结构、程序、操作一起合练,那样问题会集中爆发。
6. 比赛现场调试:从装箱清单到临场排障
6.1 赛前装箱与检查清单
去北京选拔赛现场之前,一定要做一次完整装箱演练。建议用清单核对,而不是靠脑子记:
- VEX 机器人本体。
- V5 主控器、V5 智能电机、备用电机。
- VEX 电池至少两块以上,电量确认充好。
- 电池充电器、现场可用的电源条件确认。
- 编程电脑,VEXcode 版本和电机固件版本确认。
- 备用程序工程文件,最好本地和 U 盘各一份。
- 各种螺丝、螺母、轴、轴承、扳手、螺丝刀等常用工具。
- 备用的连接线、传感器。
- 把本队机器人的关键参数表打印出来,如电机端口、齿轮比。
- 队伍联络人手机里存好场地安排和裁判区位置。
装箱演练的作用很直接:比赛前一天发现少带一个常用工具,还能补救;到了现场才发现,就只能到处借,心态也会受到影响。
6.2 现场调试的标准流程
到了比赛现场,第一件事不是跑场地,而是按顺序检查设备:
- 检查主控器固件和电脑端 VEXcode 是否匹配。
- 给机器人上电,确认屏幕显示正常、电池电量充足。
- 检查所有电机是否能够正常转动,仔细听是否有异常噪声。
- 逐一测试传感器读数,尤其是光学传感器在比赛现场灯光下的读数。
- 确认操控手柄和主控器连接正常,按键映射无误。
- 在场地上跑一次低速直行和一次低速转弯,确认机构没有卡滞。
- 再跑一次完整自动程序,用秒表记录完成时间,与训练数据对比。
这里最容易犯错的是:到了现场直接用训练时的传感器阈值,结果比赛场地灯光一换,视觉传感器识别失常。所以现场测试时一定要重新检查传感器环境相关参数。
6.3 突发问题处理顺序
比赛现场出现问题时,团队的默认动作应该是“先恢复,再诊断”,而不是当场拆机器人。
常见处理顺序是:
- 释放控制器和主控器的所有按键,停止当前动作。
- 观察主控器屏幕有没有报错码,比如电机过流。
- 检查电池电压是否过低。
- 检查是否有螺丝脱落导致机构卡死。
- 如果是程序问题,先回退到上一个稳定版本,而不是继续现场改代码。
- 记录当前故障现象,等比赛结束后再深入分析。
如果某一轮自动阶段失败了,不要急着在仅剩几分钟内重写整段自动程序。更稳妥的做法是保留此前已验证的版本,先确认失败是不是因为机械故障或现场校准问题。临时改代码容易引入新问题。
7. 高频故障排查表:现象到根因的检查顺序
7.1 故障现象与排查对照
下面这张表中,部分问题在现场出现频率很高,适合打印出来贴到工具箱里:
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 电机不动 | 接线松动、端口写错、电机过流 | 检查端口定义和连接线,看主控器报错 | 重新插紧连接线,确认程序端口号,等待电机冷却 |
| 机器人自动跑偏 | 惯性传感器未校准、轮子打滑、底盘不对称 | 打印传感器读数,校准传感器,检查轮胎磨损 | 增加启动校准流程,在直行中闭环纠偏 |
| 程序突然停在中途 | 电机过流保护、代码死循环、电池低电量 | 看主控器日志,测量电池电压,检查程序分支 | 让电机停止冷却,排查卡死位置,回退稳定程序 |
| 传感器读数跳动 | 环境光干扰、接线接触不良、物体距离过近 | 在主控器打印原始终数值,移动机器人观察变化 | 调整传感器安装位置,重新校准阈值,检查接线 |
| 动作慢、无力 | 电池电压低、齿轮比过大、电机方向冲突 | 更换满电电池,检查传动链是否卡滞 | 确认电池状态,优化传动比,取下卡滞零件 |
| 结构晃动 | 螺丝松动、轴承缺失、结构件变形 | 逐个检查关键连接点,晃动负载机构 | 加防松垫圈,拧紧螺丝,补强受力点 |
7.2 现场排障顺序原则
排查时不要跳跃式检查。顺序上先确认外部物理状态,再看程序逻辑。具体是:
- 机器人是否在安全状态,有没有卡死或掉零件。
- 电池电压是否正常,主控器是否报错。
- 接线和端口定义是否与当前程序一致。
- 传感器数值是否可信。
- 程序逻辑是否能覆盖当前场况。
- 回退到最近一次成功版本,确认是否是代码变更导致。
这条顺序看似简单,但能避免很多“调了半天,最后发现是电池没电”的尴尬。
8. 工程记录与团队协作:让经验在队内流通
8.1 机器人版本记录
一台比赛机器也会像软件一样升级。建议给机器人建立版本概念,比如 V1.0 初版、V1.2 提高取物结构刚性、V2.0 更换底盘传动比。每次大的结构或程序变更,都要记录变更时间、变更内容和验证结果。
版本记录不用很复杂,一张表格或一个共享文档即可:
| 版本 | 日期 | 变更内容 | 验证结果 | 负责人 |
|---|---|---|---|---|
| V1.0 | 2025-10-12 | 初版底盘,两组四电机驱动 | 直行稳定,取物成功 8/10 | 张三 |
| V1.1 | 2025-10-20 | 更换取物夹爪 | 夹取成功率提高到 9/10,但重心偏高 | 李四 |
| V2.0 | 2025-11-05 | 重新布置电池,底盘加宽 | 转弯稳定,取物成功率稳定 | 王五 |
这份记录最大的作用是:当现场调试时发现某个问题,能很快判断是不是最近一次改动带来的,以及要不要回退。
8.2 代码版本管理与回滚
VEX 程序同样建议纳入版本管理。即使团队不用 Git,也可以使用简单的文件归档方式:每次比赛日结束后,把当天的.v5code或 VEXcode 工程文件另存为带日期和版本号的文件。
autonomous_v1_0_1025.v5code autonomous_v1_1_1101.v5code autonomous_v1_1_1103_backup.v5code autonomous_v1_2_1108.v5code如果使用 Git,提交信息尽量写清楚“为什么改”。例如:
fix: 转弯后未复位惯性传感器,导致第二次转弯角度不准 - 在 turnTo 函数开头重新 setHeading(0) - 增加转弯完成后 100ms 稳定等待好的提交信息比什么都重要。比赛现场时间紧张,没有人能靠记忆还原“上一版为什么好、这一版改了什么”。
8.3 团队职责与交接
一个稳定的参赛队伍,通常要有明确分工:
- 结构负责人:维护机构版本,负责螺丝巡检和现场机械故障。
- 程序负责人:维护工程文件,负责自动程序、传感器校准和代码回滚。
- 操作手:负责手柄控制、联队沟通、训练数据反馈。
- 记录员:负责比赛数据记录、录像分析、文档归档。
但分工不意味着互不关心。机械负责人要理解程序为什么需要传感器安装在一个便于校准的位置,程序负责人也要知道机械负载对电机电流的影响。赛前可以安排角色互换测试:让操作手去跑一次自动程序调试流程,让程序负责人试一次结构拆装。这样每个人都知道另一个位置的工作难点,现场协作效率会明显提高。
9. 安全、合规与赛后复盘
9.1 电池使用与存放安全
VEX V5 电池容量较高,备赛和比赛现场都要注意安全使用:
- 不要使用外壳破损、鼓包或触点明显损坏的电池。
- 充电时使用配套充电器,不要随意更换充电接口。
- 不要边充电边给机器人上电运行,避免过流。
- 电池不要放在高温环境,比如封闭车内或阳光直射的桌子上。
- 备赛结束后把电池电量保持在干燥、阴凉的存放环境。
比赛现场如果出现电池发热异常,停止使用并交给现场负责人处理,不要自行拆开。
9.2 规则合规检查
比赛前一定要完成规则合规自查,不要等裁判检查才发现问题。常见检查点:
- 机器人最大尺寸是否超过当赛季规则上限。
- 使用零件是否是规则允许的零件类型。
- 扩展零件数量、切割和加工方式是否符合规定。
- 机器人是否在连接主控器时有裸露的金属边缘,可能划伤其他队伍或场地。
- 气动系统是否有正式安装,是否经过充放气检漏。
如果拿不准,宁可删掉可能违规的装饰件,也不要冒失去比赛资格的风险。北京选拔赛作为区域选拔赛,规则审查通常严格执行官方的比赛手册,队伍应在出发前逐条对照当赛季官方规则手册进行自查。
9.3 赛后复盘与下一步规划
比赛结束后,不管成绩如何,都建议在 3 天内做一次完整复盘,因为此时的记忆最具体。复盘内容包括:
- 自动阶段的成功率和失败原因。
- 手动阶段哪几个动作耗时最多。
- 现场排障花了多长时间,有没有更快的方法。
- 与其他队伍联队配合时,沟通和指令是否清晰。
- 装箱清单里哪些东西带多了、哪些其实很必要。
复盘结果要写下来,而不是口头总结。如果团队继续参加后续赛事,这些记录能直接派上用场。如果是第一次参加 VEX 机器人竞赛的新队伍,这次比赛积累的经验甚至比名次更重要。
对于即将参加 2026 VEX 机器人竞赛北京选拔赛的队伍,最值得做的准备不是把机器人做得更复杂,而是把以下环节跑到熟练:结构装配和螺丝巡检、传感器校准检查、自动程序回退、现场故障排查、装箱清单核对、比赛规则自查。这些环节都稳定了,机器人才能在场上稳定输出。