简介：这套面向中鸣超级轨迹赛的模块化程序包，以循迹控制为核心，兼顾比赛管理、计时统计与成绩汇总等场景，适合参赛选手、指导教师在备赛和赛事组织中使用。压缩包共72个文件，以33个C语言源程序、28个rcu配置文件和5个bin烧录文件为主，另有sb2、txt、doc等说明文档，整体仅813KB，便于快速分发与部署。程序内容覆盖传感器数据读取、路径实时计算、PID调节、硬件I/O通信与串行通信等关键环节，从E3/E2更新说明和20160510版更新日志中还能理清版本迭代思路，模块划分清晰，可直接用于中鸣机器人平台的二次开发。已有1225人学习下载。通过阅读源程序与配置文件，既能理解循迹小车的完整控制链路，也能获得比赛模块划分、防作弊处理及异常调试的实践参考，对提升机器人控制与嵌入式开发能力有明显帮助。 做中鸣超级轨这个比赛项目，我最大的感受是：真正拉开成绩差距的，往往不是谁的车更快，而是谁的代码在比赛现场不乱套。很多队伍在练习场地能跑满分，一换场地就疯狂翻车，要么在十字路口原地打转，要么在断线区域冲出跑道——问题大多不是出在算法上，而是程序本身就写成一团乱麻，改一个参数牵连整个逻辑。这篇内容就围绕超级轨比赛的模块化Arduino程序设计来聊，重点说清楚一个核心问题：程序模块到底该怎么分。
1. 超级轨项目的技术本质：为什么不能一个循环从头写到尾
先说清楚超级轨这道题是什么。简单讲，机器人要沿着一条由黑色轨迹线组成的赛道自主行驶，途中会经过直线、直角弯、锐角弯、十字交叉口、断线区，甚至模拟的交通标志停车点。整套任务看似是“沿着一条线跑”，但对程序来说，它要处理的是一个连续变化的物理世界，而不是一帧一帧的静态画面。
很多新手拿到这类比赛，最容易写出的代码长这样：一个loop()函数，里面有几百行，从读传感器到算电机PWM全部堆在一起，再用几个if判断当前该走直线还是该转弯。这种写法在刚通电调试的时候看起来没什么问题，因为赛道简单、车速慢、光线稳定。可一旦上了真实赛场，车速提上来，场地反光变化，电池电压掉下来，同一个if的判定结果就会变得不稳定，这时候你想针对某一个环节做优化，往往会发现牵一发动全身。
所以“模块划分”不是比赛之外的软件工程洁癖，而是比赛成绩的基本保障。只有把传感器读值、逻辑判决、电机执行拆成相对独立的单元，你才能在赛前有限的时间里，快速定位“到底是传感器数据不对，还是转弯策略笨”这类问题。
1.1 赛道元素的多样性，决定了程序必须是状态机
超级轨的赛道很少是单纯的一条线。常见的元素包括：
- 普通直线段，考验基础巡线的稳定性。
- 连续S弯，考验转向响应速度。
- 十字交叉口，机器人要判断是直行还是转弯，不能只盯着“是不是在线外”。
- 断线/虚线区，传感器可能短暂丢失黑线，程序要有“记忆”和“预测”能力。
- 直角弯甚至锐角回头弯，需要提前降速和强制转向。
- 停车线/障碍区，需要切换到另一个动作模式。
这些元素如果全部塞进一个线性执行的loop里，表达式会爆炸式增长：每个if都要考虑前面是什么状态、后面可能是什么状态，逻辑复杂到你自己都改不动。更好的做法是用状态机的方式组织：机器人永远处于某个明确的状态（例如“巡线中”“过十字”“过断线区”“停车等待”），状态之间的切换条件由传感器事件触发，每个状态内部只处理自己该做的事。这样程序结构天然就模块化了。
1.2 传感器和执行器的非理想性，决定了模块必须有余量
另一个容易被忽略的点是：底层硬件不是一个理想函数。灰度传感器的读数会受环境光、赛道材质老化、传感器安装高度影响；电机和车轮之间还存在机械惯性，PWM值稍微调大一点，车头就可能冲过头。所有这些不确定性，放在一个耦合极重的程序里，互相叠加之后非常难修。模块化的环境里，你至少可以单独验证每一段数据的可信度，比如先把传感器值打印到串口确认数值范围，再决定阈值怎么取。这比对着整份代码猜来猜去要高效得多。
2. 程序模块怎么分：按数据流拆，不按代码行数拆
回到那个很实际的问题：进行Arduino程序设计的时候，应该怎么区分程序的模块？我的划分原则有一条：看数据是怎么流动的，而不是看代码怎么写方便。一辆比赛机器人，数据流本质上是一条链：物理世界 → 传感器 → 数据处理 → 决策 → 执行器 → 物理世界。按这条链切分模块，每个模块的职责边界是天然清晰的。
2.1 第一层：传感器采集与预处理模块
这一层负责把模拟世界变成可信的数字信号，对外只暴露“拿到当前几个探头的状态”。以常见的5路或8路灰度阵列为例，原始模拟量在每一场比赛的每一次点亮之后都可能不同，所以模块内部至少要做三件事：
- 读取模拟值，做多次采样取平均，或做简单的滑动滤波。
- 根据阈值把模拟量转成二值化数组，例如
1表示压到黑线，0表示白底。 - 把数组编码成一个特征值，比如“3号探头压线”“左侧偏出”，供上层直接使用。
这一层最忌讳的是把阈值判断写在主循环里。阈值是一种需要频繁标定的参数，最好集中存放在一个配置区，采集模块统一读取。
2.2 第二层：巡线策略决策模块
这一层是核心，它只负责回答一个问题：“根据当前传感器特征和历史状态，我下一步该往哪个方向调整？”常见做法是查表或条件分支，比如Error = 特征值对应的位置偏移，然后PID控制器根据Error计算转向量。这一层不应该去直接操作电机引脚，而是把计算结果输出成一个“转向修正量”或者“目标差速比”，交给下层执行。
为什么这样分？因为调试的时候，你经常需要单独验证一件事：传感器看到的特征到底对不对。只要特征判断逻辑独立出来，你可以用串口监视器看着当前特征值，再手动推车跑一遍赛道，观察模块输出的决策量是否合理。如果特征模块和决策模块混在一起，你就无法区分“读错了”还是“算错了”。
2.3 第三层：状态机与任务调度模块
超级轨不是一个纯巡线任务，它还可能包含计时、停车、等待等环节。状态机模块负责管理当前任务阶段：是刚起步、正常巡线，还是遇到十字准备直行，还是抵达终点停车。它依赖第二层提供的特征判断结果，但不会直接读取传感器。模块内部通常是一个switch-case结构，每个分支代表一个状态，每个状态里有明确的进入条件、执行动作和退出条件。
比赛现场经常出现的“莫名其妙的乱跑”，绝大多数是状态机出了问题——比如从“过十字”状态没有正常回到“巡线”状态，因为退出条件写得过于苛刻，或者两个状态之间的转换被重复触发。状态机独立成模块之后，你可以在代码里加一个简单的状态打印，跑车时通过蓝牙或OLED实时观察当前在哪个状态，排查效率会高很多。
2.4 第四层：电机驱动与执行模块
这一层最简单也最容易出问题。它接收上层给出的目标速度、转向量，然后换算成左右电机的PWM值，再调用电机驱动库输出。关键点是：所有PWM方向映射、电机极性修正，必须在这一层内完成。如果电机装反了要调整，你只改这个模块，不需要去翻决策逻辑。很多队伍新装机之后发现车往后退，然后去改决策代码里的正负号，这就是模块边界不清晰造成的混乱。
3. 模块的接口长什么样：一份可复用的代码骨架
划分好模块之后，接下来要解决的问题是接口怎么定义。我个人习惯先把数据结构定义好，再写模块，这样每个模块之间只通过结构体和枚举交流，不会出现某个全局变量被三个地方乱改的情况。
下面给出一份适合超级轨比赛的代码骨架，可以直接在这个基础上改。
// 传感器特征枚举 enum LineFeature { ON_LINE, // 正常压线 LEFT_OUT, // 偏左 RIGHT_OUT, // 偏右 CROSSROAD, // 十字路口特征 LOST // 丢线 }; // 任务状态枚举 enum RunState { STATE_IDLE, STATE_START, STATE_LINE_FOLLOW, // 正常巡线 STATE_CROSS, // 过十字路口 STATE_BROKEN_LINE, // 过断线区 STATE_STOP // 停车 }; // 传感器数据包 struct SensorPacket { int raw[8]; // 原始ADC值 bool binary[8]; // 二值化结果 LineFeature feature; // 特征判读结果 }; // 决策输出 struct MotionCommand { int baseSpeed; // 基础速度 int turnCorrection; // 转向修正量 }; // 全局共享数据 SensorPacket g_sensor; MotionCommand g_motion; RunState g_state = STATE_IDLE; unsigned long g_stateStartTime = 0;3.1 传感器模块怎么把模拟量变成特征
传感器的预处理模块，我通常会独立成两个函数：一个负责采集和滤波，一个负责特征识别。采集部分需要根据比赛场地情况反复调整阈值，所以把阈值统一定义成宏或全局变量，方便集中修改。
// 采集 + 滤波 + 二值化 void sensor_update() { // 每个探头连续采5次，去掉最大最小，取平均值 for (int i = 0; i < NUM_SENSORS; i++) { int sum = 0; for (int j = 0; j < 5; j++) { sum += analogRead(SENSOR_PINS[i]); delayMicroseconds(500); } g_sensor.raw[i] = sum / 5; g_sensor.binary[i] = (g_sensor.raw[i] < THRESHOLD[i]) ? 1 : 0; } } // 特征识别：只输出上层关心的枚举值 LineFeature sensor_get_feature() { int count = 0; // 压线探头数量 int weightedSum = 0; // 加权位置 for (int i = 0; i < NUM_SENSORS; i++) { if (g_sensor.binary[i]) { count++; weightedSum += i * 100; // 位置权重 } } if (count == 0) { return LOST; } if (count >= NUM_SENSORS - 1) { return CROSSROAD; } int center = weightedSum / count; if (center < CENTER_MIN) return LEFT_OUT; if (center > CENTER_MAX) return RIGHT_OUT; return ON_LINE; }这段代码里有一个值得注意的细节：CROSSROAD的判断用了count >= NUM_SENSORS - 1而不是count == NUM_SENSORS。因为实际赛道的十字路口不一定所有探头都能同时压到黑线，稍微有一点点偏，就会有一个探头悬空。如果卡死“全部压线”才认为是十字，那么你就可能永远识别不到十字路口。
3.2 决策模块怎么把特征变成转向量
决策模块的核心是“误差→控制量”的映射。我推荐至少用一个简单的比例控制做基础版本，如果车子高速过弯摆得厉害，再考虑PD控制。关键是给决策模块一个干净的数据入口，它只做数学计算，不碰传感器引脚。
MotionCommand decision_compute(LineFeature feature, int baseSpeed) { MotionCommand cmd; cmd.baseSpeed = baseSpeed; cmd.turnCorrection = 0; switch (feature) { case ON_LINE: // 正常巡线，用特征偏置计算误差 cmd.turnCorrection = g_sensor.center - OPTIMAL_CENTER; break; case LEFT_OUT: // 偏左，需要向右修正 cmd.turnCorrection = -FIXED_TURN; break; case RIGHT_OUT: cmd.turnCorrection = FIXED_TURN; break; case LOST: // 丢线：保持上一拍输出，避免突然急转 cmd.turnCorrection = g_lastCorrection; break; case CROSSROAD: // 十字路口：策略在状态机里决定，这里只回传基础值 cmd.turnCorrection = 0; break; } g_lastCorrection = cmd.turnCorrection; return cmd; }这个模块最容易犯的错误，是把“丢线”处理成“猛打方向回去找线”。真实赛场上丢线往往发生在高速过弯或者断线区，此时猛打方向反而会导致车子斜着飞出去。我的做法是让决策模块输出“保持上一拍的控制量”，同时降低基础速度，状态机再决定是按断线逻辑继续往前，还是进入强制转弯逻辑。
3.3 状态机模块怎么写才能不互相干扰
状态机的写法有很多种，超级轨这种规模的任务，用最简单的switch-case就够了。我这里重点说两个原则：一是每个状态都要有超时保护，二是状态退出条件要写在状态内部，不要写在主循环里。
void state_update() { static unsigned long crossStartTime = 0; switch (g_state) { case STATE_IDLE: if (digitalRead(START_BUTTON) == LOW) { g_state = STATE_START; g_stateStartTime = millis(); } break; case STATE_START: // 起步加速 0.5 秒，避免打滑 if (millis() - g_stateStartTime > 500) { g_state = STATE_LINE_FOLLOW; } break; case STATE_LINE_FOLLOW: if (sensor_get_feature() == CROSSROAD) { g_state = STATE_CROSS; crossStartTime = millis(); } else if (sensor_get_feature() == LOST) { g_state = STATE_BROKEN_LINE; g_stateStartTime = millis(); } break; case STATE_CROSS: // 过十字时直行 300ms，再回到巡线 if (millis() - crossStartTime > 300) { g_state = STATE_LINE_FOLLOW; } break; case STATE_BROKEN_LINE: // 断线区：如果又看到线，回到巡线；超时 800ms 按挺住处理 if (sensor_get_feature() == ON_LINE || sensor_get_feature() != LOST) { g_state = STATE_LINE_FOLLOW; } else if (millis() - g_stateStartTime > 800) { g_state = STATE_STOP; } break; case STATE_STOP: // 停车等待，直到手动复位 break; } }很多人在写状态机时忽略了一个细节：状态的进入时间记录。比如进入STATE_CROSS之后，要记录这一刻的时间戳，等300毫秒后再切出。如果没有这个时间戳，程序会反复检测到十字特征，然后一直卡在同一个状态里出不来。时间戳变量一定要是static或者模块级变量，不要用局部变量，否则退出函数就丢失了。
4. 模块联调的艺术：先单独测试，再整体合体
模块写完之后，千万不要直接拿去赛道上跑完整流程。真实赛场调试的时间非常有限，你要用最短的时间定位问题，联调顺序直接决定效率。
4.1 单独检测试阶段
第一步，把传感器模块单独跑起来。写一个临时程序，只调用sensor_update()和sensor_get_feature()，把结果通过串口发到电脑上。然后，把机器人放在赛道的不同位置——线上、线外、十字正中间、断线起点——观察串口输出的特征值是否符合预期。这一步能过滤掉绝大多数的阈值和安装问题。如果某个探头在某个位置读数不对，优先检查传感器高度和角度，而不是改代码。
第二步，测试电机模块。把驱动函数单独运行，让机器人原地左转、右转、前进、后退各一秒，确认动作正确、方向正确。尤其要确认左右轮在同一个PWM值下是否跑得直，如果明显偏，就需要在电机模块里加上转向标定，而不是靠决策模块的 PID 去硬拉回来。有个小技巧：在电机的PWM输出端分步调试，先输出固定15%占空比观察是否能正常启动，防止起步死区导致比赛时车子原地不动。
4.2 拼装后的信息流追踪
模块合体之后，问题会主要集中在状态切换的时序上。这时候我习惯在状态切换时打印一条串口日志，比如：
Serial.println("LINE_FOLLOW -> CROSS at 1234ms");跑完一圈之后，对照日志看状态切换是否符合预期。比如过十字时，LINE_FOLLOW -> CROSS应该出现一次，然后CROSS -> LINE_FOLLOW在300ms后出现。如果日志显示CROSS和LINE_FOLLOW在几十毫秒内疯狂交替，说明退出条件判断太灵敏，需要增加延迟或者增加多次确认计数。
4.3 参数标定的先后顺序
超级轨的参数标定是有顺序的，顺序错了会越调越乱。我建议的顺序是：先标电机速度（确定基础速度上限），再标传感器阈值（保证二值化稳定），然后标PID比例参数（保证直线稳定），最后加状态机逻辑（处理特殊元素）。有不少队伍上来就调 PID，结果发现车身抖动，调到后面才发现是左右轮结构差异造成的，这就是顺序没理清。基础速度也要按“弯道能跟住，直道不甩尾”来设定，先定一个基础值，再根据现场赛道微调。
5. 比赛现场的高频翻车点与我的处理习惯
这部分完全来自我在各类场地调试的真实经验，不整理出来总感觉差点意思。
5.1 电池电压变化导致的参数漂移
这个坑非常隐蔽。新电池满电时，电机PWM输出猛，车子速度很快，转弯看起来干脆利落。跑了两三轮之后电压下降，同一个PWM值下速度变慢，原有的PID参数就偏保守，车子在弯道上开始“画龙”。所以我一般会在代码里做一个简易的电压补偿：读取电池电压，当电压低于某个阈值时，统一把基础速度乘一个小于1的系数，同时稍微增大转向修正量。这个逻辑放在决策模块里，用一两行代码就能实现。
5.2 场地灯光干扰与传感器阈值
室内的照明环境和室外完全不同。在教室调试时传感器的阈值，到了比赛场馆经常偏掉，尤其是那种有阳光直射的玻璃棚场馆，黑色胶带的反射值会变得很不稳定。我的做法是：每到一个新场地，先跑一个“阈值标定程序”，让机器人在黑线和白底上各采集10次数据，串口输出平均值，然后把新阈值写进代码。不要凭经验拍脑袋改一个数，那样你只会误伤其他环节。
5.3 改一个参数影响全局的连锁反应
这是模块边界不清晰最典型的症状。比如你把基础速度从60调到80，结果发现车在十字路口冲过了停车点。表面上看是“速度太快”，但根因可能是状态机里过十字的时间还是固定的300ms，速度上去之后这300ms里的行驶距离变长了。这种问题如果在结构化程序里，根源会非常清楚：速度参数、状态机时间参数、位置参数三者分开，调整任何一个都不应该影响另外两个。我给出的骨架里，baseSpeed和crossDuration是独立参数，调整速度时只需要重新计算过十字需要的行驶距离，然后修改状态机的定时参数即可。
6. 几个容易被忽视但能救命的调试技巧
最后分享几个我实际比赛时经常用的小技巧，不涉及高深理论，但真的能救命。
第一，串口输出加开关。写完代码后，把所有的Serial.println包在一个调试宏里，平时关闭，到了新场地需要排查时才打开。有些队伍全程开着串口输出，结果每次跑圈时间都多出几百毫秒，对比赛成绩影响很大。
第二，给电机模块加一个安全超时。如果状态机卡在某个状态超过5秒，强制停机并闪烁LED，避免机器人一头撞出赛道。这个功能能保护电机和场地设施，也能在调试时快速发现状态机死锁。
第三，车轮打滑和传感器悬空是两个极易混淆的现象。如果车子在起步时刻原地不动或者跑偏，先检查轮子是否打滑，再检查传感器。打滑问题要减速起步、改变轮胎表面；传感器问题才是代码层的修正。很多人在赛场上改了一下午代码，最后发现是轮胎磨损严重，这个教训非常深刻。
模块化设计在超级轨这类比赛里，真正的作用不是让代码结构看起来漂亮，而是让你在有限的时间里，最快地找到“现在到底应该改哪里”。每一层模块只和上下层通过接口沟通，数据流向单一可追踪，赛场上压力再大也不至于全盘重写。如果你正在准备超级轨比赛，不妨先把这套骨架跑通，再逐步往里面加自己的策略细节。
本文还有配套的精品资源，点击获取
