Arduino智能小车实战：硬件选型、PID调参与调试全攻略

深夜的实验室里，一辆巡线小车在同一个弯道冲出去了三次。车轮空转的声音越来越刺耳，我看着串口监视器里的误差数据，脑子里只有一个判断：转向补偿给大了，Kp值需要调。关掉电源，拔掉电池，重新烧录，再上电测试。这类场景对玩 Arduino 机器人的人来说太熟悉了。它不像网上视频里那么顺滑，也没有“三分钟让你的小车动起来”那么轻松，它的真实面貌是一堆杜邦线、降压模块、电机驱动板、PID参数和反复烧录组成的循环。但这恰恰是 Arduino 机器人制作最有价值的部分。

这篇内容会以一辆以 Arduino 为核心的双轮差速小车为主线，从硬件选型、供电方案、控制逻辑、PID调参，一直讲到赛前现场调试和 Arduino 向上进阶的路径。我不会跟你谈那些听起来高深但用不上的概念，只讲我在实际项目中反复验证过的东西，包括哪些元件值得买、哪些写法会让系统卡死、现场比赛前最容易挂掉的几个细节。适合刚接触 Arduino 想做一个完整机器人的新手，也适合准备参加巡线、竞速、相扑类机器人比赛但缺少系统经验的队伍参考。

1. 先选对硬件：机器人的“骨架和肌肉”不能随意搭

很多人做 Arduino 机器人第一步就卡在选型上。打开购物网站，看到主控板、电机驱动、超声波模块、舵机、电池的一堆选项，根本不知道从哪下手。其实机器人项目的硬件选型不是越贵越好，而是要围绕三个问题展开：它需要完成什么任务、需要在多复杂的物理环境里工作、后续要扩展哪些传感器。把这三点想清楚，选型就不会乱。

1.1 主控板选型：从 Uno、Nano 到 Mega、ESP32

Arduino 家族里最常见的几块板子，我直接用实际项目经验告诉你该怎么选。

做普通的两轮小车，我建议直接用 Nano，原因很直接：Uno 其实内部芯片和 Nano 一样，但体积大一截，放在小车底盘上占空间、走线也乱。Mega 适合什么项目？我做过一台同时带五路循迹、两路编码器、三个超声波和一个机械臂的小车，主控用 Uno 明显吃力，因为 IO 不够，定时器和中断资源也捉襟见肘，这时才值得上 Mega。ESP32 的定位不太一样，它性能更强、自带无线，适合做进阶的联网机器人，但 3.3V 逻辑电平、ADC 精度和 Arduino 生态的兼容性都需要额外处理，入门项目不建议一上来就啃它。

选型还有一个容易忽略的点：中断引脚资源。做机器人基本离不开编码器测速，而编码器读取要用外部中断。Uno 和 Nano 可用的外部中断引脚只有 2 和 3，两个电机刚好占满，如果后续还想加第二个传感器的中断输入，就只能用引脚变化中断模拟，代码复杂度马上上升。所以我会在项目规划阶段就把中断需求算进去，而不是等焊完线才发现不够用。

1.2 电机驱动与供电：最容易翻车的一环

电机驱动方案常见的有 L298N、TB6612、DRV8833。很多人一开始图省事用 L298N 模块，因为它便宜、面包板友好、插线方便，但它内部用的是双极性晶体管方案，饱和压降能到 2V 左右，意味着 7.4V 电池供电时电机实际能拿到的电压可能只有 5V 出头，转速和扭矩都打折，模块本身还烫得厉害。相比之下 TB6612 和 DRV8833 是 MOSFET 方案，压降小很多，效率高，体积也小，适合对安装空间有要求的小车。

我自己的标准配置是：N20 减速电机加霍尔编码器，配 TB6612 驱动。N20 电机便宜、耗电低、扭矩对小型巡线车足够，编码器版本可以在不增加结构复杂度的情况下拿到轮速反馈。如果你只是做避障类的慢速小车，普通 TT 电机也能用，但没法精确控制轮速差，转向全靠估算，而估算在比赛中往往就是失败的原因。

供电这块才是真正的重灾区。很多新手犯过一个低级错误：用 USB 给 Arduino 供电，然后电机驱动也从同一个 5V 引脚取电。电机启动瞬间电流能冲到 1A 以上，USB 口根本扛不住，Arduino 直接重启。解决办法是独立供电：电池电压先给电机驱动板，再从驱动板上带稳压输出的引脚给 Arduino 供电，或者单独用一节 9V/12V 电池给 Arduino 的 Vin。电池方面，两节 18650 锂电池串联出来的 7.4V 是小型电机小车的甜点电压，容量也够支撑一整天的调试。但注意 18650 有放电倍率的区别，电机瞬间需要大电流，买的时候要选能持续输出 2A 以上的动力电池。

提示：Arduino 的线性稳压芯片 AMS1117-5V 从 Vin 取电时，输入电压越高，稳压芯片上的压差功耗越大，发热越明显。用 12V 给 Vin 供电会严重发热，7.4V 是比较合适的区间。

地线回流也是一个常见隐患。电机驱动的大电流回路和传感器的信号回路如果共用一条细地线，电机会把噪声耦合进传感器信号里，表现为超声波距离乱跳、巡线数值不稳定。规范做法是：电机驱动的地和 Arduino 逻辑地单点相连，避免大电流地线回路经过传感器区域。这个毛病排查起来非常隐蔽，我踩过一次坑，折腾了一晚上，最后把地线重新整理一遍就全好了。

2. 让小车按你的思路跑起来：编程的核心框架

硬件搭好之后，接着就是 Arduino 的固件逻辑。这里我要先说一个很多教程不会强调的问题：Arduino 的 loop 循环本质上是单线程裸机程序，如果你用 delay 做时间控制，程序在 delay 期间什么都干不了，所有传感器采样、中断处理、串口输出全部冻结。对跑在赛道上的机器人来说，这意味着你永远无法在一个精确的时间窗口内同时完成多件事。

2.1 非阻塞状态机：让主循环高效运转

看一段典型的反面代码：

void loop() { digitalWrite(motorA, HIGH); digitalWrite(motorB, LOW); delay(1000); digitalWrite(motorA, LOW); digitalWrite(motorB, HIGH); delay(1000); }

这段代码的效果是电机先正转 1 秒再反转 1 秒，但如果中途我要检测传感器并紧急停车，系统不会响应，因为它在 delay 的睡眠里。正确思路是使用非阻塞的时间判断，把控制流程抽象成一个状态机。

enum RobotState { STOP, RUN, TURNING, FINISH }; RobotState state = STOP; unsigned long stateStartedAt = 0; void setState(RobotState newState) { state = newState; stateStartedAt = millis(); } bool isStateElapsed(unsigned long ms) { return millis() - stateStartedAt >= ms; } void loop() { // 读取距离传感器 int distance = readUltrasonic(); switch (state) { case STOP: if (distance > 20) setState(RUN); break; case RUN: setMotorSpeed(200, 200); if (distance <= 20) { setState(TURNING); } break; case TURNING: // 原地转向，持续 500ms setMotorSpeed(-120, 120); if (isStateElapsed(500)) { setState(RUN); } break; case FINISH: setMotorSpeed(0, 0); break; } }

这种写法看起来不如 delay 直观，但它有两个巨大优势：首先，状态切换与耗时动作都不会阻塞主循环，传感器读取延时再长也不会让电机响应停止；其次，程序的行为边界非常清晰，便于在后面叠加 PID 反馈控制时保持逻辑稳定。

使用millis()还有一个被很多人忽略的细节：millis()返回的是unsigned long，约 50 天后会溢出归零。标准做法是用减法而不是比较大小来判断时间差，因为无符号整数的溢出语义会自动处理回绕问题，millis() - lastTime >= interval这个表达式即使 millis 回绕也是正确的。这也是为什么我在上面的代码里都用millis() - stateStartedAt，而不是去找对时间戳。

2.2 电机 PWM 和舵机 PWM：频率不能混为一谈

Arduino 里的 PWM 就是通过快速切换数字引脚的高低电平，来改变电机或舵机的有效电压/信号。很多人第一次用电机时直接用analogWrite(pin, 150)，发现电机只在特定占空比附近才转得平稳，有些转速区间还会啸叫。原因在于analogWrite在 Uno/Nano 上的默认 PWM 频率大约是 490Hz 或 980Hz，这个频率落在人耳听觉范围内，线圈会发出可听见的电磁噪声，而且低到一定程度后，电机在每个周期内可能无法累计足够能量启动，导致低速死区明显。

更关键的是舵机对 PWM 的要求。舵机信号不是占空比驱动功率，而是脉宽编码指令：标准的模拟舵机期望 50Hz 信号，高电平时间在 1ms 左右对应一个方向极限，1.5ms 对应中位，2ms 对应另一个方向极限。如果你用 analogWrite 类似的思路去输出一个高得多的 PWM 频率，舵机的控制脉冲就会出现混乱，表现为舵机滋滋抖动或乱转。

所以我做项目时会明确区分两套 PWM：

• 电机驱动 PWM 频率：如果用 TB6612/DRV8833，可以显式设置定时器把 PWM 频率提高到 15kHz 到 20kHz，超出人耳听觉范围，而且高频下电流纹波更小，电机低速运行更线性。
• 舵机 PWM：用 Arduino 官方的 Servo 库，或者自己用定时器精确输出 50Hz、脉宽 500us 到 2500us 的脉冲。Servo 库默认使用 Timer1，如果在同一个项目里还要用另一个定时器做电机 PWM，需要你搞清楚芯片的定时器资源分配，避免相互覆盖。

注意：UNO/Nano 上标准 Servo 库使用 Timer1 产生舵机脉冲，而 analogWrite 的某些引脚使用 Timer0/Timer2。同一个定时器被多个库同时抢占时，通常表现为某个引脚输出完全失效或系统运行变慢。排查方法很简单：逐个注释掉初始化代码，看故障是否消失。

3. 从直行到过弯：PID 参数到底怎么调

巡线机器人是理解 PID 最好的载体。传统玩法是数字量循迹，传感器输出有线和无线两种状态，程序检测到偏左就往右修一点。这种方式在低速和小角度弯道下能跑，但速度一快就露出原形：轮子每修正一次都是一次猛打方向，车走出来的轨迹是锯齿形的，弯道里经常甩出去。

PID 的核心是给控制量一个连续、渐变的修正。前提是你得先把每个传感器的位置变成一个数值化的“偏差量”。我在五路循迹模块上通常将传感器按照位置赋权，读到一个数组后用加权平均算出当前线位置：

const int sensorPins[5] = {A0, A1, A2, A3, A4}; const int sensorWeights[5] = {-2, -1, 0, 1, 2}; float readLinePosition() { float weightedSum = 0; float activeSum = 0; for (int i = 0; i < 5; i++) { int value = analogRead(sensorPins[i]); // 阈值已通过校准程序提前保存在全局变量里 if (value < threshold[i]) { // 低于阈值视为检测到黑线 weightedSum += sensorWeights[i] * 1.0; activeSum += 1; } } if (activeSum == 0) { // 全部丢线，返回一个特殊值，由上层逻辑决定怎么搜线 return 99; } return weightedSum / activeSum; }

线在车体正中间时，位置值等于 0，偏左是负值，偏右是正值。这个位置信息进入 PID 控制器后，把误差值映射成差速补偿，小车就能很平滑地跟随曲线。

3.1 把位置式 PID 写进 Arduino

下面是一个精简但实用的位置式 PID 实现，代码里我把采样时间放在调用端控制，这样积分和微分都基于真实的物理时间变化。

float targetPosition = 0; // 目标：让线保持在正中间 float previousError = 0; float integral = 0; float lastTime = 0; float pidUpdate(float currentPosition, float kp, float ki, float kd) { unsigned long now = micros(); float dt = (now - lastTime) / 1000000.0; // 防止刚启动时 dt 过大导致微分项爆掉 if (dt <= 0 || dt > 0.1) { dt = 0.01; } float error = targetPosition - currentPosition; // 限制积分项，防止长时间丢线后积分饱和 integral += error * dt; if (integral > 100) integral = 100; if (integral < -100) integral = -100; float derivative = (error - previousError) / dt; previousError = error; lastTime = now; return kp * error + ki * integral + kd * derivative; }

然后在主循环中按固定周期调用它，再把 PID 输出换算成左右轮速度。

void controlLoop() { float linePos = readLinePosition(); if (linePos == 99) { // 全部丢线，表示冲出赛道，执行急停或搜索 setMotorSpeed(0, 0); return; } float correction = pidUpdate(linePos, kp, ki, kd); float baseSpeed = 180; // 基础速度 int leftSpeed = baseSpeed - correction; int rightSpeed = baseSpeed + correction; // 限制输出范围 leftSpeed = constrain(leftSpeed, -255, 255); rightSpeed = constrain(rightSpeed, -255, 255); setMotorSpeed(leftSpeed, rightSpeed); }

这段代码的精髓在于误差符号与差速方向的匹配。拿我开头的例子来说，如果线偏在车体右侧，readLinePosition 返回正值，correction 为正，则左轮加速、右轮减速，车体会主动向右修正，方向刚好对上。很多新手 PID 调不出来，一半原因是代码逻辑没错但正负号配反了，小车越跑越偏直到冲出赛道。

3.2 调参流程与现场记录

调 PID 是个手艺活，但也有套经过验证的流程：

• 第一步，把 Kp、Ki、Kd 全部归零，只留一个很小的 Kp，比如 0.2，观察车在直线上的表现。小车应该开始出现轻微摇摆。
• 第二步，逐步增大 Kp，直到车在直道上以目标速度运行时开始震荡，记录这个临界值，然后退回临界值的一半左右作为初始 Kp。
• 第三步，加入 Ki。积分项可以消除稳态误差，但小型巡线车直线段的稳态误差本来就很小，Ki 加多了反而会在弯道引起严重的积分饱和，所以 Ki 值通常只需要非常小，比如 Kp 的 1/50 甚至更小。
• 第四步，最后加 Kd。微分项能提前抑制误差变化趋势，我常用的经验是 Kd = Kp 的 5 到 10 倍，但这个数字取决于你的采样周期和编码器反馈质量，不能生搬硬套。

调参的过程必须做记录。我之前带学生参加比赛时，经常看到有人调了半个小时，感觉差不多了，就一个参数一个参数地瞎拧，结果一跑圈又不行，还回不到上一个能跑的版本。所以我习惯在代码注释里写上每次修改的日期和数值：

// 2025-04-12 弯道内侧甩尾，Kp从1.8降到1.2 // 2025-04-12 直道低速抖动，Kd从8升到12 float kp = 1.2; float ki = 0.02; float kd = 12.0;

光在代码里记录还不够，最好配合串口把偏差量和输出值实时打印出来。用 Arduino IDE 自带的串口绘图器，把linePos和correction打出来，你能直接看到小车过弯时的误差曲线和修正行为。这比单纯看车跑圈要高效太多，很多肉眼观察不到的异常在曲线上会一目了然。

3.3 定时中断保证采样周期稳定

上面的 PID 代码里，我用micros()算 dt，但调用频率如果忽高忽低，控制效果也会飘。更可靠的做法是让 PID 在固定时间周期内执行，比如每 10ms 控制一次。Arduino 上最直接的实现是用定时器中断，但裸机写定时器比较麻烦。一个折中方案是在主循环里维护一个时间阈值判断：

unsigned long lastControlTime = 0; void loop() { // 读取与显示等耗时的任务 if (millis() - lastControlTime >= 10) { lastControlTime = millis(); controlLoop(); } }

这个写法虽然还是有微小的抖动，但 10ms 的控制周期对巡线小车完全够用。只要保证主循环单次执行时间不超过 2ms 左右，抖动影响就非常有限。如果项目规模大了，需要多路传感器同时采样再加上串口通信，建议把控制任务直接写进定时器中断里，但那会带来更复杂的资源冲突管理，属于进阶玩法，这里不展开。

提示：控制周期一定要满足香农采样定理的思路，至少是系统响应频率的 5 到 10 倍，否则数字控制会引入额外的延迟，表现为小车动作总比传感器反馈慢半拍。

4. 比赛环境下的实战调试术

到了这一步，小车基本能在测试跑道上稳定跑完一圈了。但如果你要把它带到比赛现场，下面这些内容才是决定你能否拿名次的关键。比赛环境与实验室环境有两个巨大的区别：光线不可控、时间窗口紧。很多人程序在实验室跑得好好的，一到赛场就失控，原因大多不是算法坏掉了，而是底层的传感器阈值和数据采集环节经不起环境变化。

4.1 把比赛任务拆成一个个可验证的状态

千万不要直接对着完整赛道写一个大循环。我看到的比赛队伍有一个共同的毛病：只在最后一天整合测试，结果出问题了，不知道是传感器问题、控制参数问题还是程序逻辑问题。正确的做法是第一步就把任务拆成若干独立子状态：

• 启动：等待发车信号或按键，然后沿直线前进。
• 直线行驶：保持车头方向，快速稳定推进。
• 左/右弯道：根据信标或轨迹信息提前减速，按预设曲率过弯。
• 交叉线处理：检测到小十字标志时，不执行换向动作。
• 终点停车：检测到第二条停车线后减速并完全停止。

每一个状态都对应明确的传感器输入和输出动作。状态与状态之间要留足切换的可靠依据，比如从直线进入弯道，不一定非要靠地理坐标，可以依靠线位置持续偏向一侧超过一定时间来判断。这种拆解方式也对单步调试友好，你可以在测试场地上人为放置一个弯道信标，单独验证弯道子状态，完全不受其他逻辑干扰。

4.2 现场光线干扰与阈值自动校准

循迹传感器本质是红外反射强度检测，检测到黑线时反射率低、输出高阻或逻辑翻转，白底时反射率高。问题是不同赛场的白底材料、黑线印刷质量、灯光色温都不一样，同一套阈值根本不能通吃。

我做的校准办法是在程序启动时等待 3 秒，让选手把五个传感器全部贴在白色底板上，Arduino 自动读取每个通道的最大值，然后让传感器依次扫过黑线，记录最小值，最后把阈值设为最大值与最小值的中间值。

int sensorMax[5] = {0, 0, 0, 0, 0}; int sensorMin[5] = {1023, 1023, 1023, 1023, 1023}; int threshold[5] = {0, 0, 0, 0, 0}; void calibrateThreshold() { // 假设发车前有 3 秒校准窗口 Serial.println("Calibrating..."); unsigned long start = millis(); while (millis() - start < 3000) { for (int i = 0; i < 5; i++) { int v = analogRead(sensorPins[i]); if (v > sensorMax[i]) sensorMax[i] = v; if (v < sensorMin[i]) sensorMin[i] = v; } delay(5); } for (int i = 0; i < 5; i++) { threshold[i] = (sensorMax[i] + sensorMin[i]) / 2; Serial.print("Threshold["); Serial.print(i); Serial.print("] = "); Serial.println(threshold[i]); } }

校准过程看似简单，但里面有个坑：传感器最小值不一定是 0，最大值也可能受环境光干扰。如果校准窗口内传感器没有完全覆盖到黑线和白底两个极端情况，算出来的阈值就存在问题。所以在正式测试时，我会把校准程序的输出值通过串口打印出来，用肉眼确认每个阈值都在合理的量级。如果某个通道的最大最小差值过小，说明传感器可能被遮挡或损坏，这时候修程序和改算法都没用，直接换硬件才快。

4.3 比赛现场只改一个变量

再说一个赛场纪律：到现场后，最容易失控的行为是频繁改代码。赛事时间往往以小时计，每次改完代码要经历编译、烧录、上电校准、跑圈测试，一个环节不顺，十几分钟就没了。而很多参数是耦合的，你同时调 Kp 和基础速度，出了问题根本不知道哪个是元凶。

我的原则很明确：现场只允许做两类调整。第一类是传感器阈值，通过我们内置的校准程序一键完成；第二类是全局速度上限和 PID 参数。而且修改时只动一个变量，改了之后跑一圈记录结果，不行就退回到上一条可用的记录。为了做到这一点，我在主程序开头集中定义了所有可变参数，并把当前版本号打进串口。

const int RUN_VERSION = 18; int baseSpeed = 210; // 基础速度 float kp = 1.2; float ki = 0.02; float kd = 12.0; int turnSpeedLimit = 150; // 弯道限速

如果第 18 版跑砸了，我能立刻改回一个常量的数字重新烧录，而不是在几十行代码里翻找哪个参数被改过。这个方法听起来很笨，但它能保证你在比赛时间窗口内始终工作在“可复现版本”上，而不是越调越乱。

5. 再往上走：Arduino 如何与更现代的机器人生态衔接

完成一台能完成赛道的 Arduino 小车之后，很多人会问：这东西和外面讲的 ROS2、激光雷达、AI 视觉、多传感器融合这些概念之间到底是什么关系？是不是我一开始就应该直接学那些高级框架？

我的看法是：Arduino 不是过时的玩具，它在整个机器人系统里承担着一个不可替代的角色——实时执行层。你可以把机器人系统分成三层：感知层、决策层、执行层。视觉和激光雷达这类大算力传感器更适合放在树莓派、Jetson 或工控机上跑，路径规划算法适合用 ROS2 这类中间件去编排，但真正驱动电机完成动作、采集编码器数据、控制舵机到达指定角度这类需要低延迟、高可靠性、直接操作寄存器的任务，用 Linux 操作系统加一堆软件栈反而容易因为调度延迟而出问题。所以 Arduino 在多数机器人项目里扮演的仍然是靠近硬件的那一层。

5.1 串口通信：上位机与 Arduino 协作的基础

学 Arduino 机器人到一定阶段，串口通信是绕不开的。上位机通过 USB/UART 发送指令，Arduino 解析并驱动电机；同时 Arduino 把编码器数据、ICM 数据传回上位机做融合和显示。这个过程是很多机器人架构的雏形。

串口通信的代码基础很容易，难点在于自订协议的设计。我常用的协议格式是：

$M,150,-150# // 电机控制指令 $S,30# // 舵机角度指令 $Q# // 请求状态上报

解析用简单的状态机逐字节处理：

void parseSerialCommand(char c) { static char buffer[32]; static int bufIndex = 0; static bool inCommand = false; if (c == '$') { inCommand = true; bufIndex = 0; } else if (inCommand && c == '#') { buffer[bufIndex] = '\0'; executeCommand(buffer); inCommand = false; bufIndex = 0; } else if (inCommand && bufIndex < sizeof(buffer) - 1) { buffer[bufIndex++] = c; } }

为什么不直接按行读？因为在中断里逐字符读时，\n在不同系统里会有\r\n的区别，很多新手被这个坑害过。用特殊字符作为帧头和帧尾，协议自包含更强，也不需要依赖行结束符的兼容性。这是我自己做上位机联调时沉淀下来的经验。

5.2 ESP32 与无线调试：脱离 USB 线的约束

当你想调试运动中机器人的动态数据时，USB 线是最大的束缚。小车一跑起来，数据线要么拽着车跑，要么传感器线的电感噪声干扰串口信号。把主控换成 ESP32 或者用一个 ESP32 模块做无线透传后，数据能无线回传到电脑上，调试体验会完全不同。ESP32 在 Arduino 环境下的生态已经非常成熟，直接支持 WiFi、蓝牙、OTA 固件升级，这类功能放到 Uno 上想都不要想。

换成 ESP32 时有一点要注意：ESP32 的 IO 电平是 3.3V，而很多常见的 5V 传感器模块和电机驱动板的逻辑输入是 5V。直接连接虽然在很多板子上能碰巧工作，但长期可靠性没保障。稳妥做法是传感器和驱动接口加电平转换，或者直接选用带 3.3V 兼容说明的模块。

不过我的建议仍然是：不要过早从 Uno/Nano 跳到 ESP32。先把基础的控制逻辑、PID、状态机在结构简单的 8 位单片机上做到滚瓜烂熟，你才能理解高级平台里那些“友好”的工具背后到底帮你处理了什么问题。

5.3 开源硬件社区资源怎么用

Arduino 能火起来，Linux 式的开源精神功不可没。硬件图纸、代码库、接线图、案例教程，几乎都可以在网上找到，而且多数以许可证形式授权使用。如果你是新手，与其一个人闭门造车，不如大量参考别人做过的项目。

参考代码有两个原则必须守住。第一，不要复制粘贴后直接烧录，要挑一个能看懂核心逻辑的库或例程，在它的基础上改动，因为它默认的引脚配置、时序逻辑可能和维护者自己的一套配件匹配，换个硬件就失效。第二，使用第三方库前先看许可证，非商业学习用途还好，如果要基于它做商业产品或者参加一些不允许开源的封闭赛事，许可证要求可能完全不同。养成看 Readme 和 License 的习惯，是一个开源硬件开发者的基本素养。

6. 高频故障排查速查与开发习惯建议

最后把我在 Arduino 机器人项目中碰到的高频故障整理成一张速查表。每个问题我都亲自踩过，排序按出现的概率来。

6.1 关于中断、串口与电源的三条独门建议

第一，不要用 delay 控制启动等待，然后在等待期间靠键盘给发车信号，因为 Arduino 的delay期间会屏蔽很多东西的处理。我在很多比赛方案里看到的解决方案是，程序启动后只初始化但不运动，直到串口收到一个字节再进入自动控制流程，这样的等待是零消耗的。

第二，串口绘图器和实时波形输出是调试利器，但不是每个串口数据都值得打印。数据一多，串口就变成了程序性能的瓶颈，控制循环被阻塞。我的经验是，调试时打印原始值，测试运行时只打印状态切换和关键错误，减少串口占用对系统稳定性的影响。

第三，给电池电压留出裕量。新车充满电跑一圈下来，电压从 8.2V 慢慢掉到 7.2V，你如果只在满电状态下调参数，电压一降，电机的最大转速、响应速度都变化了，小车就跑不出同样水平。比较好的习惯是：赛前用放电了一些的电池做最终测试，实战时也提前了解电池在哪个电压范围小车最稳定。

6.2 值得坚持的开发习惯

做到这个阶段，技术细节反而没那么重要了，更值钱的是工作习惯。我自己坚持了三件事：代码版本管理用 Git，哪怕是一个人做的小项目也建仓库，每次能跑的版本都打一个 tag，现场出了问题可以秒回滚；调参数据用笔记本或 README 记录，日期、赛道照片、参数、跑圈结果缺一不可；硬件电路不要贪图省事用热熔胶糊弄一切，关键接点要焊，插线要扎带固定，不然赛前颠簸几下，松一根线就什么都没了。

这些习惯不会让你编程更炫酷，但能在关键时刻救你一命。我做 Arduino 机器人这多年，印象最深的不是某个算法的突破，而是某个比赛前夜，我把所有版本的参数打印出来，对比之后发现当天下午调的一套参数其实是最优的，然后果断回滚。第二天小车跑出了整个队伍在训练中最好的成绩。开源硬件开发的世界里，真正的进步大部分时候不是灵光一现，而是靠这些琐碎的习惯一点点垒起来的。