无视觉版智能车：先稳运动控制，再谈视觉识别

“21届走马观碑车模运行视频（未加入视觉）”这个标题，很多人看到后的第一反应可能是：既然项目叫“走马观碑”，视觉识别才是核心，没加视觉是不是意味着只是个半成品？我的看法恰恰相反。在智能车和竞赛车模这类项目里，“未加入视觉”不是一个缺项，而是一个被太多团队跳过去、最后又回来补课的里程碑。

车模和普通的小车 demo 有本质区别。它更接近一个真实系统：电池供电所以电压会掉，机械结构存在摩擦，电机有死区，编码器有噪声，处理器控制周期不完全是固定间隔。只要有一环没稳住，就算摄像头已经识别出赛道和标牌，车也早就冲出去了。很多团队连续几周调视觉仍然跑不出成绩，不是因为识别不够准，而是底层运动控制没有给视觉提供一个稳定平台。这种情况在智能车竞赛、电子设计竞赛以及机器人毕设里反复出现。

所以这篇文章，我想借“21届走马观碑车模运行视频（未加入视觉）”这个案例，把无视觉阶段到底解决了什么问题、需要哪些硬件和软件基础、运动控制代码怎么写、运行结果怎么验证、常见坑有哪些，完整拆解一遍。无论你是在做竞赛车模、课程设计，还是独立机器人项目，这套“先把车开稳，再让车看懂路”的开发顺序，都值得长期参考。

1. 项目名里最容易被低估的四个字

“走马观碑”这个项目名取得很有意思。字面意思是行走的马经过碑文时快速浏览，对应到车模项目上，可以理解为小车在运动中识别路侧标志物或文字。目标是运动与视觉的结合，但从视频标题来看，当前版本只完成了前一半：让车先跑起来，而且跑得稳。

这个开发节奏是值得赞赏的。很多人一接到车模项目，就迫不及待地安装摄像头、跑深度学习模型、做目标检测，结果车一动就翻，或者识别到了目标但车根本来不及反应。原因不复杂：视觉感知解决的是“看到什么”，运动控制解决的是“车稳不稳”，两者是串行关系，不是并行关系。视觉识别需要稳定的画面，需要相机随车体运动时不会因为抖动产生模糊，需要底盘能在规定时间内完成转向和刹车。这些前提条件没有满足，视觉算法再快也没有用。

从“未加入视觉”这个阶段要交付的结果来看，至少包含这几项能力：

• 电机的 PWM 驱动可靠，正反转切换无异常。
• 编码器能准确测量车轮转速，数据不丢脉冲。
• 速度环可以稳定输出，直线不跑偏，急停不甩尾。
• 转向机构响应灵敏，舵机或差速转向有明确的中位。
• 车模支持串口或遥控方式下发指令，方便后续扩展。

这些能力全部打通之后，视觉模块才是一个“可插入”的增量。否则所谓视觉版，就是在不稳定底板上叠一个更不稳定的模块。所以在分析这个视频时，真正值得看的东西不是“现在能跑多快”，而是“它是否建立了一条可以继续接入视觉的稳定基线”。

本节可以给出一个明确结论：“未加入视觉”不是这个项目的短板，而是它最扎实的起点。后续加视觉，如果效果不好，回滚到这个版本也是一种有效的调试手段。没有这个基线，后续所有调优都缺乏参照物。

2. 无视觉版车模的系统拆解与运行逻辑

车模和普通桌面小车最大的不同，是它必须按照“输入→控制→执行→反馈→修正”的闭环模型工作。很多初学者写小车代码，习惯写成开环：向前走 1 秒，停止，转弯。这种方式在无负载、平整桌面上勉强能跑，一旦放到真实赛道或复杂地面，结果完全不可控。因此车模项目从第一天起就应该按闭环系统设计。

从硬件角度看，一个典型的无视觉版竞赛车模由以下几部分构成。注意这里不写死具体型号，不同学校、不同比赛的方案差异很大，但功能模块基本一致。

从软件角度看，无视觉版车模的程序并不复杂，但它必须有一个清晰的主循环结构。最忌讳的是把所有代码都堆在loop或者while(1)里面，导致某一帧执行时间过长，控制周期抖动。一个合理的软件数据流大概是这样的：

遥控或串口指令先进入“指令解析模块”，解析后的目标速度与目标转向角度被送入控制算法。速度环根据编码器反馈计算 PWM 输出，转向控制根据舵机角度映射输出对应脉宽。底层还要有一个监控模块，负责检测电池电压、编码器异常、通信超时，并在异常时执行安全停车。

无视觉版虽然不处理图像，但依然可以做很多事。最简单的是遥控模式，适合测试硬件和控制参数；进阶一点是预置轨迹模式，让车按照固定的速度曲线和转向曲线跑；再进阶可以做基本的直线保持、循线（如果是电磁或红外），甚至可以利用编码器实现简单的里程计，估算行驶距离。这些都不需要摄像头，却能为视觉版提供非常宝贵的运动学模型数据。

这一节的关键在于理解：车模是一个实时闭环系统，代码结构必须为主循环的确定性服务。先把这个意识建立起来，后面写成什么样都不会太偏。

3. 开发环境与工具链准备

在实际开始写代码之前，环境准备决定了后面调试效率。如果你的项目还在早期，请先花半天时间把工具链理顺，不要上来就插电跑车。

首先是集成开发环境。不同主控有不同选择，STM32 系列常用 Keil 或 STM32CubeIDE，Arduino 系列用 Arduino IDE 或 PlatformIO，MSP430 用 CCS。工具的选择不是最重要的，重要的是你能完成编译、烧录、调试三步闭环。建议在拿到板子后第一个任务是点亮板载 LED，确认工具链没问题，而不是直接写 PID。

其次是串口调试工具。车模调试几乎离不开串口。常见 Windows 下推荐 Vofa+、SerialPlot，或者直接用 Python 写一个简单的串口绘图脚本。串口的作用有两个：一是打印内部状态，包括目标速度、当前速度、PID 输出、控制周期，二是远程下发指令。这里建议统一使用 115200 波特率，数据结构做到简单可解析，方便后续做上位机。

然后是电源与测量设备。车模调试期间强烈建议使用稳压电源供电，而不是只靠电池，因为稳压电源可以限制电流，防止 PID 参数爆错导致电机堵转时烧毁驱动。万用表用于检查电压、通断、共地状态。对于电机 PWM 波形、编码器相位等信号，如果条件允许，用逻辑分析仪或示波器看一眼，很多怪问题立刻就有答案。

最后是机械检查工具。车模跑不直，很多时候不是算法问题，而是前后轮不平行、左右轴承阻力不一致、轮胎磨损不均匀。在写任何控制代码之前，手动推一下车，检查四个轮子是否顺畅；悬空抬起车，用手转动电机轴，感受传动阻力是否均匀。这类机械问题如果没有在前期排除，后面 PID 参数无论怎么调都会很奇怪。

环境准备的整体思路可以归结为一句话：先保证“可观察、可控制、可限制”，然后再开始写运动控制代码。可观察指有串口或显示屏能看到内部变量，可控制指能通过指令让电机启动和停止，可限制指供电和输出都有保护机制。

4. 核心运动控制实现：主循环、电机驱动与速度 PID

这一节是整篇文章的重点。我们以 Arduino 风格代码为例，讲解无视觉版车模最核心的运动控制实现。之所以用 Arduino 风格，是因为它便于展示整体逻辑，且在实际项目中经常作为快速原型工具。如果你使用的是 STM32 或其他 MCU，逻辑完全一致，只是底层寄存器或 HAL 库函数不同。

4.1 主循环设计

车模主循环不应该是一个大 while 套所有功能，而应该是一个固定时间片调度器。常见的做法是：10ms 执行一次舵机控制，20ms 执行一次速度环，50ms 上传一次串口数据，200ms 检查一次电压。这样每个任务都有确定的时间资源，不会互相干扰。

// 文件：SmartCar_NoVision.ino // 说明：无视觉版本车模运动控制示例，使用 Arduino 语法封装。 // 实际项目请根据主控型号、电机驱动板、编码器相数进行适配。 #include <Encoder.h> // 电机输出引脚 const uint8_t PIN_PWM = 5; const uint8_t PIN_IN1 = 7; const uint8_t PIN_IN2 = 8; // 编码器引脚 const uint8_t PIN_ENC_A = 2; const uint8_t PIN_ENC_B = 3; // 控制周期 const unsigned long intervalMs = 20; unsigned long lastControlMs = 0; // 目标速度与当前速度（编码器每秒脉冲数） float targetSpeed = 0.0f; float currentSpeed = 0.0f; // PID 参数与中间变量 float Kp = 1.2f; float Ki = 0.08f; float Kd = 0.00f; float pidError = 0.0f; float pidIntegral = 0.0f; // 编码器对象 Encoder myEncoder(PIN_ENC_A, PIN_ENC_B); void setup() { pinMode(PIN_PWM, OUTPUT); pinMode(PIN_IN1, OUTPUT); pinMode(PIN_IN2, OUTPUT); Serial.begin(115200); Serial.println("SmartCar NoVision Start"); motorStop(); targetSpeed = 800.0f; // 请按实际赛道调整 } void loop() { // 串口指令解析，例如输入 t500 表示设置目标速度为 500 if (Serial.available() > 0) { String cmd = Serial.readStringUntil('\n'); cmd.trim(); if (cmd.startsWith("t")) { float value = cmd.substring(1).toFloat(); targetSpeed = value; pidIntegral = 0.0f; Serial.print("Set target speed: "); Serial.println(targetSpeed); } } // 固定周期执行速度环 if (millis() - lastControlMs >= intervalMs) { runSpeedControl(); lastControlMs = millis(); } } void runSpeedControl() { long count = myEncoder.read(); myEncoder.write(0); // 将 20ms 内的脉冲数换算为每秒脉冲数 currentSpeed = count * (1000.0f / intervalMs); float error = targetSpeed - currentSpeed; pidIntegral += error; pidIntegral = constrain(pidIntegral, -1000.0f, 1000.0f); float output = Kp * error + Ki * pidIntegral + Kd * (error - pidError); pidError = error; output = constrain(output, -255.0f, 255.0f); setMotorOutput((int)output); // 串口输出调试数据 Serial.print("target="); Serial.print(targetSpeed); Serial.print(" current="); Serial.print(currentSpeed); Serial.print(" output="); Serial.println((int)output); } void setMotorOutput(int speed) { if (speed >= 0) { digitalWrite(PIN_IN1, HIGH); digitalWrite(PIN_IN2, LOW); analogWrite(PIN_PWM, speed); } else { digitalWrite(PIN_IN1, LOW); digitalWrite(PIN_IN2, HIGH); analogWrite(PIN_PWM, -speed); } } void motorStop() { digitalWrite(PIN_IN1, LOW); digitalWrite(PIN_IN2, LOW); analogWrite(PIN_PWM, 0); }

这段代码的核心逻辑是三部分：串口指令解析、固定周期速度环、电机方向与 PWM 输出。初学者最容易忽略的是intervalMs的确定性。代码里通过millis() - lastControlMs >= intervalMs实现非阻塞延时，每次进入速度环后重置时间戳，保证主循环不会被delay卡死。

代码中使用了 Arduino Encoder 库，它依赖外部中断读取编码器脉冲。如果你用的是 STM32，通常会配置一个定时器为编码器模式，让硬件直接完成正交解码，这种方式更可靠，不占用 CPU 中断。无论如何，编码器读出的“脉冲数/控制周期”必须换算成统一单位，否则 PID 参数会随着控制周期变化而失去意义。

4.2 电机驱动：PWM 与正反转

setMotorOutput函数解决了电机正反转和调速问题。直流电机驱动板通常有 IN1、IN2、PWM 三个关键输入。IN1 和 IN2 决定方向，PWM 决定占空比。同一时刻 IN1 和 IN2 不应该同时为高，否则进入刹车状态。这里的实现是：speed 为正时 IN1 高、IN2 低；speed 为负时反过来；speed 为 0 时两个引脚都拉低，电机滑行。

这段代码里真正容易踩坑的地方是 PWM 频率。不同驱动板对 PWM 频率要求不同，有的支持几 kHz，有的在 20kHz 左右更安静。如果 PWM 频率太低，电机会有可听见的啸叫或抖动，速度环会表现为往复振荡；频率太高，驱动板 MOS 管开关损耗增大，发热严重。Arduino 默认的analogWrite频率约 490Hz，对部分电机驱动板可用，但对直流减速电机来说偏低。实际项目中建议查阅驱动芯片手册，设置合适频率。

4.3 编码器测速与速度换算

编码器是整个反馈闭环的“眼睛”。光电编码器和霍尔编码器都是常用方案，输出 A、B 两路相位相差 90 度的方波。通过判断 A、B 相先后顺序，可以同时得到速度和方向。这里有一个关键点：编码器的数据必须在每个控制周期内完整读取，并清零计数，避免累计误差。

在示例代码中，20ms 内读取一次计数并写回 0。那么currentSpeed = count * (1000.0f / intervalMs)计算的就是每秒脉冲数。如果你的编码器是每圈多少脉冲，电机减速比是多少，还可以进一步换算成实际轮速（m/s），但在控制环内部统一为脉冲数并不影响 PID 工作。

初学者经常遇到的编码器问题是丢脉冲：线束太长、接触不良、未共地、或者引脚中断被其他高优先级任务阻塞。排查方法很简单，用手慢慢转动电机轮，观察串口打印的编码器值是否平滑递增或递减。如果数值跳变或方向时正时负，先查接线和共地，不要急着调 PID。

4.4 PID 速度环调参逻辑

示例中使用了位置式 PID 的离散形式。Kp * error是比例项，负责快速消除当前偏差；Ki * pidIntegral是积分项，负责消除长期稳态误差；Kd * (error - pidError)是微分项，负责抑制超调。车模速度环通常可以先用 PD 控制，只有当稳态误差明显时再引入积分。

调参顺序建议固定为三步：

第一步先设 Ki 和 Kd 为 0，只保留 Kp。把从 0 加到目标速度的响应打出来，观察有没有稳态误差、超调量多大、响应时间多长。如果 Kp 太小，车加速慢；如果 Kp 太大，车会明显抖动，甚至发出嗡嗡声。第二步加入 Kd，主要看超调是否减小。第三步加入 Ki，消除稳态误差。整个过程每改一个参数只改一个变量，记录曲线，不要同时改两三个参数。

这里真正容易踩坑的地方是积分饱和。示例中增加了pidIntegral = constrain(pidIntegral, -1000.0f, 1000.0f)，就是把积分项限制在一定范围内。如果没有限幅，车被障碍卡住时，误差持续累加，积分项涨到极大值，等障碍消失后车会猛冲出去。这也是很多车模“一解锁就飞出去”的原因之一。

5. 转向控制：舵机中位与无视觉循道基础

速度闭环负责让车按目标速度行驶，转向控制则决定车往哪里走。无视觉版虽然没有图像识别，但转向控制必须有，否则只能直走。在竞赛车模中，常见的转向方案有两种：舵机转向和差速转向。前者适合后驱或四驱模型车，后者适合麦克纳姆轮或普通两轮差速底盘。

舵机转向的核心是 PWM 脉宽控制。一个标准舵机通常接收周期约 20ms、脉宽在 1000us 到 2000us 之间的信号，中间值 1500us 对应中位。车模跑不直的最常见原因不是算法，而是舵机中位没有校准。如果硬件安装时舵机臂没有在中位对齐，即使控制代码输出 1500us 的脉宽，车轮仍然是偏的。

#include <Servo.h> Servo steerServo; // 舵机中位对应的脉宽（微秒） int midUs = 1500; int steerAngle = 0; // -45 到 45，表示转向角度 void setup() { steerServo.attach(9); steerServo.writeMicroseconds(midUs); delay(500); } void loop() { // 简单映射：转向角度增量对应脉宽增量 int pulse = midUs + steerAngle * 5; pulse = constrain(pulse, 1000, 2000); steerServo.writeMicroseconds(pulse); delay(20); }

这段代码展示了舵机中位设置与角度映射的思路。每个舵机的中位可能不同，脉宽增量与实际角度的比例也可能不同，因此实际项目中必须做一次标定：把车抬起，分别写入 1000us、1500us、2000us，用角度尺或肉眼记录前轮角度，再建立映射表。

无视觉版如果要实现自动直线或简单循线，还可以结合 IMU。陀螺仪测量车体的航向角速度，积分后得到航向角，通过一个 PD 控制器输出舵机修正量。这里要提醒的是，直接积分会产生漂移，且底盘振动会严重污染原始陀螺仪数据。不要指望一个未滤波的 MPU6050 原始数据能直接用于航向保持。更稳的做法是先用互补滤波或姿态解算库，获得相对干净的姿态角，再把姿态角输入转向环。

6. 运行视频怎么录、怎么看、怎么验证

回到项目标题里“运行视频”这个关键词。很多人录视频只是为了证明“我的车跑了”，但这种素材对调试几乎没有帮助。真正有价值的运行视频，应该像实验记录一样有参照、有指标、可以回放对比。特别是“未加入视觉”这个版本，它存在的意义是作为后续版本对比的基线，所以录制规范直接影响后续调试效率。

首先，机位设置。至少需要一个固定机位和一个跟随机位。固定机位放在赛道的起点或直线段旁边，保证能看到车的完整运行路径；跟随机位用于近距离捕捉轮胎、舵机、电机声音等细节。如果条件允许，可以在车顶固定一个小摄像头，记录实际第一视角画面，这对标识视觉算法很有用，但无视觉阶段不是必须。

其次，赛道参考线。地面上的赛道边缘、瓷砖缝、卷尺都可以作为参考线。视频里有了参考线，就可以从画面中判断车辆是否跑偏。如果你只是在一个空旷地录，车偏了十厘米也看不出问题，这会让 PID 调参失去依据。更专业的做法是在赛道旁放几把直尺，从不同角度拍出偏移量。

第三，叠加遥测数据。用 OBS 一类软件，可以将串口打印的目标速度、当前速度、PID 输出等数据实时叠加到视频画面上。这样观众和调试者都能看到“车跑得快”和“PID 输出在震荡”之间的因果关系。比如画面里车在直线加速，但串口数据里 current 已经超过 target，那就说明 Kp 或 Kd 有问题，目标加速变成了来回振荡。

验证运动控制质量不能只看“能跑”。至少要检查几个指标：直线段稳态误差是否小于 5%；从 0 加速到目标速度的响应时间是否在 0.3 秒以内；超调量是否小于 10%；刹车时车头是否会明显偏转。这些指标在无视觉阶段都达标后，再进入视觉阶段会更稳。

为了更直观地观察 PID 响应，可以在电脑上运行一个简单的 Python 脚本，读取串口数据并绘制实时曲线。这样判断收敛过程比看数字方便得多。

# 文件：plot_speed.py # 用于读取车模串口数据，并绘制目标速度与当前速度曲线 import serial import matplotlib.pyplot as plt ser = serial.Serial('COM3', 115200, timeout=1) fig, ax = plt.subplots() times = [] targets = [] currents = [] start_time = 0 plt.ion() while True: line = ser.readline().decode('utf-8', errors='ignore').strip() if line.startswith("target="): try: parts = line.split() target = float(parts[0].split("=")[1]) current = float(parts[1].split("=")[1]) if start_time == 0: start_time = __import__('time').time() times.append(__import__('time').time() - start_time) targets.append(target) currents.append(current) ax.clear() ax.plot(times, targets, label="target") ax.plot(times, currents, label="current") ax.set_xlabel("time (s)") ax.set_ylabel("speed (pulse/s)") ax.legend() plt.pause(0.01) except ValueError: pass # 运行后在图中观察目标速度与当前速度的跟随效果

这个脚本的核心思路是解析串口输出中的target=xxx current=xxx output=xxx格式，然后实时绘图。运行前需要修改COM3为实际串口号，并保证车模已经通电且波特率一致。如果从曲线中看到当前速度围绕目标速度不断震荡，说明 PID 参数过于激进；如果很长时间才到达目标值，说明 Kp 太小。

7. 常见问题与排查思路

无视觉版车模虽然代码量不大，但在实际运行中的问题却不少。下面这张表总结了最常见的几类现象、原因和排查方向，建议收藏到本地，调试时逐项对照。

每一条问题背后，都建议先怀疑机械和接线，再怀疑代码。原因是代码问题重复出现率高，容易被发现；而机械和接线问题往往只在特定振动条件下出现，非常隐蔽。

比如“运行一段时间后失控”这个案例。很多初学者第一反应是 PID 参数不够好，但最终发现是电池电压从满电 8.4V 掉到 6V 以下，电机驱动已经进入欠压保护状态。此时不是算法问题，是电源系统设计问题。增加电池电压监测，一旦低于阈值就减速并声光报警，可以有效避免这种情况。

8. 工程建议与最佳实践

无视觉版虽小，但工程规范不能少。以下几条是长期调车经验的沉淀，适用于竞赛车模、毕设机器人以及任何嵌入式运动控制项目。

第一条是上电安全。车模上电瞬间非常容易跑飞。正确顺序是：先开串口助手并确认能收到数据，再打开车模电源；代码初始化时，所有 PWM 引脚要先置 0，后使能驱动。很多驱动板在上电瞬间，如果没有外部拉低，MCU 复位期间的引脚是高阻态，此时驱动板可能误判为高电平，导致车轮猛转。一个硬件上的做法是给使能引脚加下拉电阻，软件上则要确保初始化顺序正确。

第二条是参数集中管理。Kp、Ki、Kd、目标速度、舵机中位这些参数不要散落在程序各个位置。应该在代码顶部集中定义，或者放在独立的头文件里。参数改用宏或常量后，调参时只改一处，还能避免版本混乱。更规范的做法是把参数放在配置文件中，通过串口指令修改，重启后生效。这样你不用每次调参都重新编译烧录，省下大量时间。

第三条是日志先行。每次运行都应该有日志，哪怕只是输出到串口，也要让关键状态可追溯。日志至少包括：时间戳、目标速度、当前速度、PID输出、舵机脉宽、电池电压。不要等到出了问题才想到加日志。如果程序崩溃或跑飞，第一件事就是看日志中最后一个正常帧是什么，问题范围一下子就能缩小。

第四条是机械与电子分开排查。调 PID 之前，先确认机械是“干净”的。手动推动车，观察四个轮子是否都正常转动，听听有没有异常摩擦声。把车悬空，用手转动一侧车轮，另一侧是否反向自由转动。机械卡涩会造成编码器读数正常但实际轮速偏低，导致 PID 输出越来越大，电机持续过流。这类问题很难通过调参解决。

第五条是安全保护。在运动控制里，必须有一个“失控保护”机制。常见做法是串口超时保护：如果连续 500ms 没有收到新的遥控或串口指令，主控自动执行刹车。加速度限制和输出限幅也属于保护机制。无视觉版看起来简单，但如果缺少保护，测试过程中撞到人或设备的风险会明显增加。

第六条是录视频、传代码、存调参记录。具体来说，每次调参后保留一份视频和对应的参数表，文件名用“日期_赛道_目标速度_Kp_Ki_Kd”这种格式。后期加入视觉后，如果发现视觉算法表现异常，可以对比同赛道无视觉版本的运行效果，判断是视觉处理问题还是底层控制退化问题。没有这种记录，调试就会变成盲人摸象。

9. 下一步：加入视觉前必须准备好的四件事

实现并验证完无视觉版本后，项目就要走向视觉增强了。这里必须提醒：不要直接拿起摄像头就接代码。从无视觉到视觉版之间，还有四件准备工作必须完成，否则视觉模块会成为下一个问题的根源。

第一件事是运动学标定。至少要知道车模的最大速度、最小转弯半径、舵机打角与转弯半径的关系、加速和刹车的极限。这些数据可以通过无视觉版测得，并将它们写成配置参数。视觉算法指导车辆行驶时，需要这些上限值来规划速度曲线，否则视觉系统给出一个超出物理能力的指令，车仍然会冲出赛道。

第二件事是接口预留。摄像头模块、图像处理板（比如 OpenMV、树莓派或K210）和主控之间，建议在硬件上预留串口、I2C 或 SPI 接口，并定义好通信协议。最简单的方式是视觉板只发送“目标角速度”或“目标方向”给主控，主控保留原有的速度环和转向环代码。也就是说，无视觉版本的底层运动控制代码应该是视觉版本的复用基础，而不是被重写。

第三件事是时间同步与帧率评估。如果视觉处理帧率只有 15fps，而速度环是 50Hz，那么每两到三帧车就走过一段不小的距离。必须评估视觉延迟对控制系统的影响，并设计前馈补偿或预测算法。这一步没有做好，视觉识别的结果即使完全正确，控制效果也会很差。

第四件事是自动回滚机制。加入视觉后，一旦检测到视觉数据长时间不可用、置信度严重下降，控制模式应自动切回无视觉的安全模式，比如直接减速停车或回到遥控模式。这个机制会极大降低实车调试的风险。

完成这四件事，视觉才不是“挂在车上的摄像头”，而是真正能辅助车辆决策的模块。这里的顺序和前面整个文章的逻辑是一致的：先稳定运动，再增强感知。控制是基础，感知是增量。

10. 最后的话

“21届走马观碑车模运行视频（未加入视觉）”这个标题虽然简短，但它其实揭示了智能车开发中最容易被忽视、也最值得记录的一个阶段。无视觉版本没有漂亮的识别画面，没有复杂的算法，但它把一个工程项目分成了可以单独验证、单独调试、单独回滚的层次。这种分层能力，恰恰是很多之后做视觉项目的人最缺的。

如果你正在做车模项目，先把无视觉版本扎实跑通，把 PID 调稳，把串口日志打通，把机械问题排查干净，从视频里建立一条可重复的测试基线。然后再把摄像头接上去，你会发现视觉调试的难度会低很多。任何高级功能，都要建立在“车真的能稳下来”这个前提上。

希望这篇文章对正在调车、准备加视觉的你有帮助。跑起来，然后慢一点，把每个环节记录清楚，比跑得快更能决定项目的终点。