企业官网建设流程全解析

1. 从“赛车游戏”到“物理世界”：机器视觉循迹到底在做什么

先问一个问题：你在手机上玩过赛车游戏吧？赛道是弯的，你得盯住屏幕里那条白线或者路缘，不断调方向盘，才能不冲出赛道。循迹小车干的是同一件事，只不过它没有“眼睛”和“大脑”，而是靠摄像头当眼睛，靠单片机或处理器当大脑，把赛道图像变成转向指令。

但这里有一个很多人上来就搞错的认知："循迹"不等于"傻追线"。传统红外对管循迹是沿着一条物理上的黑线走，传感器阵列排成一排，哪个探头压线了就往反方向打方向。而机器视觉循迹的本质是**“看懂路的结构”**——它要知道线在画面的什么位置、与车身的角度偏差是多少、前方弯道有多急，然后提前做出反应。这完全是两个量级的题目。

这几年“机器视觉”在课设、毕设、电赛里的热度一直很高，但你打开任何一个论文库，搜“基于机器视觉的循迹小车设计”，跳出来的文章十有八九是同一套模板：OpenMV图像处理 + PID控制 + STM32驱动，然后附上几张阈值二值化的截图，草草收场。真正的问题——为什么图像处理参数要这样调、为什么转向控制会振荡、为什么换个光照环境就全线崩盘——几乎没人讲清楚。

这篇文章不打算再给你默写一遍代码。我想从一个真正把车跑起来的视角，把这套系统拆给你看：方案怎么选、图像处理每一步在干什么、控制量怎么从像素坐标变成PWM占空比、以及那些只有跑车时才会踩到的坑。这篇文章适合正在做课设、准备电赛、或者单纯想搞明白“机器视觉控制实体设备”这条路线的同学。读完你至少能回答三个问题：摄像头画面里的哪条线是“有效赛道信息”？这些信息如何换算成转向量？为什么PID参数在A场地能用、换到B场地就疯了一样摆动？

顺带说一句，最近“电磁循迹”“平衡循迹”这些词也搜得很火，它们本质上是同类题目用了不同的“感知传感器”。电磁循迹用电磁感应判断赛道中轴线的位置，平衡循迹是在两轮自平衡车上叠加循迹功能。但视觉方案有一个它们都比不了的优势：信息量最大，且最接近人类驾驶的逻辑。这篇文章的很多底层思路，放大到电磁循迹、雷达避障上同样适用。

2. 方案选型：视觉模块和主控到底怎么搭才不翻车

方案选型是所有人都会做的第一步，但也是翻车率最高的第一步。你在淘宝上一搜“循迹小车”，能搜出至少五种看起来差不多的套件，价格从一百到一千都有，用的方案五花八门。先看一张对比表，再聊我怎么选。

先说结论：如果你是一个月之内要交差、或者第一次接触视觉循迹，直接选OpenMV + STM32F103，别犹豫。这不是因为我保守，而是因为这条路线的“坑”网上都有答桉，你踩进去了能爬出来。树莓派方案性能强很多，但光一个摄像头标定和Linux环境配置就能耗掉你两周时间，而且树莓派跑视觉的同时还要做控制，实时性调度一旦出问题，车会像喝醉了一样。

很多人会问一个非常经典的问题：“我能不能直接用STM32F407接一个OV7670摄像头，自己写图像处理？”我劝你趁早打消这个念头。OV7670的配置寄存器有上百个，你得手动配置输出格式、分辨率、帧率，然后面对一个非常尴尬的现实：STM32F407的主频虽然比F103高不少，但做RGB565转灰度、再二值化、再提取中线，一帧下来也要几十毫秒。循迹车对延迟极其敏感，20ms的视觉延迟加上控制延迟，过弯时误差会被放大。我见过太多人死在这一步，最后乖乖换回了OpenMV。

2.1 为什么说OpenMV是“视觉循迹的最佳入门载体”

OpenMV的本质是一个MicroPython环境下的机器视觉微控制器，核心是STM32F7系列芯片，上面跑着一个类库封装好的图像处理内核。你不需要懂寄存器、不需要管DMA传输、不需要关心图像缓冲区的内存是怎么分配的，直接调用img.binary()做二值化、img.get_regression()做线性回归提取中线，然后通过串口把计算结果发给下位机STM32。

这套架构的优势在于它把“图像处理”和“逻辑控制”在物理上隔离了。OpenMV只负责“看”和“算趋势”，STM32只负责“听”和“打方向盘”。两个系统各自干自己最擅长的事，出了问题也好排查：车走歪了，先看OpenMV发给STM32的数据对不对，再查STM32转向逻辑，不用在一个芯片里同时调试图像和控制，脑子不会乱。

实际使用中还有一个非常现实的考虑：OpenMV的IDE自带帧缓冲区预览。调图像阈值的时候，你可以实时看到摄像头看到的画面被二值化之后长什么样。这个能力在调试阶段几乎是决定性的——你调整一个阈值，画面立刻反馈，5分钟就能把赛道的二值化效果调好。如果是自己写代码在STM32上做图像处理，你得把图像通过串口或者额外屏幕显示出来，调试效率天差地别。

2.2 主控选择：STM32F103C8T6为什么是黄金之选

下位机选择STM32F103C8T6，说实话不是因为它性能有多强，而是因为：资源足够、资料最多、便宜到可以随便烧。循迹车的控制逻辑其实不复杂——接收OpenMV的串口数据、做PID计算、输出PWM到电机驱动。这些用STM32F103绰绰有余。

但有一类方案我是坚决反对的：让OpenMV直接驱动电机，不经过STM32。确实，OpenMV也有PWM输出引脚，直接连电机驱动模块也能转。但你很快会发现一个问题：循迹控制是一个高频任务，转向和速度需要在几个毫秒内响应，而OpenMV的MicroPython解释器在执行复杂图像处理时，偶尔会出现几个毫秒的调度抖动。这个抖动放在图像处理里无所谓，但放在电机控制里，车就会抖动。分开之后，STM32用定时器中断做控制，10ms一个周期稳定不飘，OpenMV那边就算偶尔慢一两毫秒，反映到车上也就是线走得稍微偏一点，不至于失控。

还有一点容易被忽视：电源系统的隔离。电机启动瞬间的电流冲击非常大，如果OpenMV和电机共用一个电源且没有做隔离或滤波，画面会出现水波纹一样的噪声干扰，严重时直接死机重启。用两块板子之后，OpenMV可以用单独的稳压模块供电，STM32和电机用另一路，干扰问题迎刃而解。这个细节在后面硬件章节再细说。

3. 图像处理的核心链路：从一帧彩色画面到一条“赛道中线”

图像处理是整个系统里最让人头痛、也最有趣的部分。很多人一上来就想着“我要让小车认识赛道的形状”，这个想法其实是错的。循迹小车的图像处理目标不是“理解赛道”，而是“找到偏差”——找到赛道中心线与画面中心线的横向偏差，以及赛道在当前画面的走向趋势。把这俩算出来，控制就水到渠成了。

完整的视觉处理链路是这样的：

彩色帧采集 → RGB565转灰度 → 阈值二值化 → 图像滤波去噪 → 赛道边界提取 → 中线拟合 → 输出偏差量和角度 → 串口发送

这条链路的每一步都有人在细节上翻车，下面挑几个关键环节详细拆开讲。

3.1 灰度化和二值化：为什么“红色赛道”会让你崩溃

先说灰度化。OpenMV输出的原始画面是RGB565格式，每个像素占两个字节，包含红绿蓝三个通道信息。做灰度化就是把彩色信息压缩成一个亮度值（Y），公式是：

Y = 0.299R + 0.587G + 0.114B

这个公式不是随便写的，它模拟了人眼对不同颜色光的敏感度。但灰度化之后的画面里，赛道和背景可能都是灰色的，区分度不够。所以接下来要做二值化：把灰度图变成黑白两色图，赛道是白、背景是黑（或者反过来）。

但这里就有一个坑，而且是最容易坑死新手的坑：用LAB颜色空间而不是RGB来做二值化。为什么呢？因为RGB三个通道是高度相关的，光照一变，三个值同时变，阈值就废了。而LAB颜色空间把“亮度”（L通道）和“颜色”（A、B通道）分开了。对于红色赛道、白色背景这类场景，你只需要在A通道设定红色的阈值范围，光照变化对它的影响会小很多。我见过太多人用RGB通道调阈值，晴天调好的参数，阴天就失效，这就是原因。

实操里最常见的做法是调用OpenMV的img.binary([thresholds], invert=0)，其中thresholds是一个包含六个数值的列表[L_min, L_max, A_min, A_max, B_min, B_max]。你只需要在IDE里打开阈值编辑器，框选赛道的颜色，工具会自动帮你生成这一组数值。注意，不要试图手动去猜这六个数字，用工具生成然后微调，效率高得多。

3.2 提取赛道中线：二值化之后你该“看”什么

二值化之后，画面变成一个黑白图。这时候的“赛道信息”是一块白色的连通区域。紧接着的问题是：怎么从这一块白色区域里提取出“赛道中线”？

常用的方法有两种。第一种是逐行扫描找左右边界，再算中点。代码逻辑是这样的：

# 伪代码示意 import sensor, image, math # 假设白的是赛道，黑的是背景 img = sensor.snapshot().binary([thresholds]) mid_x = [] for row in range(60, 120): # 只扫画面下方区域，太远的无效 row_data = img.get_row_ptr(row) # 获取该行数据 white_pixels = img.find_blobs([thresholds], roi=(0, row, 160, 1)) # 上面这行只是示意，实际不会逐行find_blobs，太慢

这个思路直观，但它的问题在于计算量大：每一行都去做 blob 检测，效率极低。实际项目中更常见的是第二种方式：整体提取白色区域，然后找整个区域的几何中心，或者用线性回归拟合赛道的走向。

OpenMV官方推荐的方法是img.get_regression(thresholds)，它返回一个line对象，包含起点、终点、角度、置信度等信息。这个函数对二值化图像做线性回归，拟合出来的线段就是赛道的中心趋势线。代码非常简单：

line = img.get_regression([thresholds]) if line: img.draw_line(line.x1(), line.y1(), line.x2(), line.y2(), color=127) # 提取偏差量和角度 err = line.x2() - img.width() // 2 # 远端偏差 angle = line.theta() # 线段角度

但用过get_regression的人肯定遇到过一个问题：当赛道是十字路口或者Y型分叉时，回归出来的那条线会找歪。因为回归是对所有白色像素做的全局拟合，分叉路口的白色像素分布是“X”型的，拟合结果会取一个折中方向，小车就会在路口犹豫甚至直冲。解决思路是用ROI框定一个“有效区域”，只让摄像头关注画面下方的一块梯形区域——那里离车最近，赛道信息最可靠，远方的信息不是不要，而是要在控制端通过历史数据进行平滑处理。

这里我强烈建议你把“有效区域”这个概念刻在脑子里。循迹不是看得越多越好，看得太远反而会引入大量干扰。你只要盯住车前15到25厘米的那条赛道，控制就已经足够稳定了。远方的弯道信息，靠的是控制算法的预判，而不是靠图像硬看。

3.3 图像滤波和噪点剔除：那一两个白色噪点是怎么骗过你的

调试的时候你肯定见过这种情况：明明赛道很干净，但二值化之后的画面里，就是会冒出几个孤立的白色噪点。噪点来自哪里？可能是地面的反光点，可能是插座上的白字，也可能是摄像头CMOS传感器的热噪点。

一个噪点带来的后果可能远超你的想象：如果你的中线提取方法是对白色像素做整体统计（比如计算白色区域的形心），那么画面上方一个离赛道十万八千里的噪点，会把形心强行拽偏几十个像素。这几十个像素经过后续比例换算，会让小车猛地朝一个完全错误的方向打一下方向，然后马上又修正回来。表现出来就是车在直道上“抽风”。

处理噪点有三个层次，按性价比排序：

1. 形态学滤波：OpenMV的img.erode()（腐蚀）和img.dilate()（膨胀）是最直接的武器。先腐蚀去掉孤立噪点，再膨胀恢复赛道原本的宽度。注意腐蚀的次数不要超过1次，否则细赛道会被“吃”掉。
2. 连通区域面积过滤：在二值化之后，用img.find_blobs()找出所有白色连通区域，然后通过blob.area()过滤掉面积太小的块。这个方法鲁棒性更好，因为它不改变赛道本身的形状，只是把“小东西”忽略了。
3. ROI限制：在上一步提到的“有效区域”里，用img.binary(roi=...)做区域二值化。画面边缘、天空区域、赛道外的杂物，压根不让它们进入图像处理的视野。

我个人的习惯是组合使用：先对全图做二值化，然后立刻做一次腐蚀（去噪），再用ROI框定有效区域，最后在这个ROI里做线性回归。这样处理之后，赛道上极少出现因为噪点导致的幽灵转向。

4. 从像素到转向：串口通信与PID控制的系统工程

图像处理把赛道中线提出来了，下一位选手该登场了——控制逻辑。但控制逻辑不是你写个if语句“如果线偏左就往左打”就完事的。这种开关量控制用在红外对管车上是凑合的，用在视觉车上基本走不了直线——它会左右疯狂摆动，像一条被踩了尾巴的蛇。

4.1 串口通信：数据格式定了，调试效率就定了

OpenMV和STM32的通信是通过串口（UART）完成的。通信内容很简单：偏差值、赛道角度、可选的速度等级。但通信格式有讲究，我先说说踩过的坑。

最蠢的做法是发送ASCII字符串，比如发 “-150,25\n”。为什么蠢？字符串拼接要时间、STM32解析要时间、数字转字符串还要时间。在10ms的控制周期里，这种浪费实在不值得。

推荐的做法是发送结构体二进制数据，比如定义数据包：

# OpenMV发送端 import ustruct, time from pyb import UART uart = UART(3, 115200, timeout_char=1000) def send_data(error, angle): # 打包格式：2个short + 1个校验字节 data = ustruct.pack('<hhb', int(error), int(angle), 0x5A) uart.write(data)

STM32端用结构体指针接收，不解析字符串、不做字符转换，拿到的直接就是int16_t，直接放进PID计算里。同理，每条链路、每个环节，能省一秒是一秒，实时性就是这样一点一点省出来的。

4.2 如何把像素坐标变成转向角：比例系数和动态方向修正

从像素到转向，中间隔着一个世界单位换算的问题。画面中心的像素坐标是 (80, 60)，假设图像宽160像素。你算出的偏移量是偏差像素值err = line.x2() - 80，正值偏右、负值偏左。接下来就是如何把这个像素偏差转成转向PWM。

最简单的基础版：

target_angle = kp * err

kp就是你需要的比例系数。注意这里算的是“目标舵机角度”而不是“PWM占空比差值”。如果你的车用的是舵机转向，舵机角度和PWM占空比是一个映射函数，需要标定。如果你的车是差速转向（两个后轮独立驱动，靠转速差转向），那target_angle就直接作为差速量加到左右轮的PWM里。

这里有一个小细节新手经常搞错：像素偏差和实际偏差不是线性关系。摄像头是透视成像，画面下方的像素代表“车附近”的赛道，画面上方的像素代表“远处”的赛道。相同的地面距离，在画面下端可能占据30个像素，在画面上端只占据5个像素。如果你的偏差计算用的是远端和近端的像素平均值，相同的地面偏移在靠近和远离摄像头时，像素值差异会很大。所以常见的做法是只关注画面下方几行的像素中心，或者像前面说的用ROI限制在近处区域，让误差信号尽量“准”。

4.3 PID讲解：P让车转向，I消除静差，D刹住振荡

PID控制本身不复杂，公式就一行：

output = Kp * error + Ki * integral + Kd * derivative

但三个系数怎么选、相互怎么配合，这才是经验所在。

先以基础的比例控制为例。如果你只用P控制，你会发现车在直道上能走，但在弯道或者着线偏移时，车转向的力度总是差那么一点，或者是转向过度、来回振荡。为什么？因为比例控制是“看着当前误差打方向”，它没有记忆、没有预判。误差大就猛地打方向，误差小就小幅转，结果在弯道里永远差一截，在直道上永远左右修。

再说D项（微分）。D项的本质是“误差的变化趋势”。误差正在快速变大的时候，意味着车正在快速冲出赛道，需要加大转向力度来阻止；误差正在快速减小的时候，说明转向已经在起作用了，D项就会给一个“刹车”信号防止过冲。你可以把它类比成：拐弯的时候，如果车速很快，你会提前多打一点方向（P作用），然后感觉到车头开始转了，你会稍微松一点方向（D作用刹车）。没有D项的小车过弯会“冲过头”，然后大幅回摆，这就是典型的“振荡”。

那I项（积分）呢？它的作用是消除静差——就是“总是差那么一点”的稳态偏差。比如车速较快时，转向机构的摩擦力会让实际转向角总比目标转向角小一点点，误差一直存在。I项把历史误差积累起来，持续输出一个补偿量，把这个“差一点点”顶上去。但I项有个大坑：积分饱和。如果你的小车在开局前就偏了一段路，积分项会在几秒钟之内积累到一个很大的值，等车回到正轨时，这个“惯性”还是会推着它继续转。解决方法有三个方向：设置积分上限、只在误差较小时启用积分、误差超过阈值时直接清零积分。

调试顺序建议是这样的：先只留P，调到直道能走、弯道能过但不振荡的程度；然后加D，重点解决弯道过冲和直道回摆；最后加I，用量控制在P项的10%-20%，用来补静差。我见过太多人一上来就上全套PID，参数一塌糊涂，车像跳机械舞一样。调PID没有捷径，但有方法论。

4.4 转向控制的“前轮预瞄”思想：视觉方案真正的优势

前面反复提到过，机器视觉循迹比传统红外对管强在“看得远”。但光看得远没用，你得会用这个“远”。如果转向控制器只看近处的误差，那远处的弯道信息完全被浪费了。

一个非常有效的改进思路是“预瞄点”模型。假设小车速度是1米/秒，控制周期是20ms，那它50ms之后会到达前方5厘米处，200ms后会到达前方20厘米处。未来会碾过的赛道才是真正需要关心的。做法很简单：不只用当前帧的偏差，而是用“当前偏差”和“未来最近一帧偏差”的组合。或者说，直接在图像处理阶段就专门提取画面中上部那条线作为“预瞄目标点”，控制端把近端误差和远端误差加权组合：

steer = w_near * err_near + w_far * err_far

权重w_far可以从小调到大：调大了，车会在远处刚看到弯道时就提前转向，过弯姿态非常顺滑，像是知道路一样。调过头了，车会过度紧张，稍微有点曲率就大幅打方向。这套思路几乎是视觉循迹超越电磁和红外方案的天然优势。传统方案想做一个“远方传感器”都做不出来，视觉方案天生就带有远方信息。

5. 硬件组装与调试实录：供电、安装角度和那些不可言说的坑

写代码之前，先看一眼硬件能撑多久。很多小车不是逻辑写得不好，是硬件扛不住。循迹小车这套系统里面，硬件的问题往往比软件更隐蔽——板子自己重启了、摄像头忽然黑了、电机有力无力地抽搐，这些问题排查起来能让人崩溃到想摔车。

5.1 供电系统的层级隔离：为什么电机一转、OpenMV就重启

电动小车的供电是第一个劝退点。常见的电池方案是3节18650锂电池串联，标称电压11.1V，充满12.6V。这里有两个问题：电机启动瞬间的压降和电磁干扰。

电机堵转或者猛加速时，瞬间电流可以到2A甚至3A，电池内阻加上导线电阻，会引起不小的电压跌落。如果你用一块LM2596降压模块，把所有系统的电都从这一路出，那电机一启动，OpenMV的供电电压可能瞬间低于它的最低工作电压（通常是5V±5%），于是系统复位。你看到的现象就是：油门一加大，OpenMV红灯闪一下，画面全黑，然后重新启动。

正确的供电方案是这样的：

电池(11.1V) ├── 大电流DC-DC降压模块 → 电机驱动模块(7.4V或按需) └── LDO/DCDC稳压模块 → 5V → OpenMV / STM32 / 舵机

电机驱动和逻辑系统的电源物理上分成两路，共地但电源路径不共用。这是一个极其重要、成本极低、但90%的新手都不注意的设计。

还有一点，舵机的电源一定要单独考虑。很多舵机（比如SG90、MG90S）在转动瞬间电流也能飙到700mA左右，如果和STM32共用一片AMS1117，分分钟把电压拉垮。给它独立从5V主电源取电，别走LDO。

5.2 摄像头安装高度和俯仰角：你看到的世界决定了控制难度

摄像头的安装决定了整个视觉系统的上限。安装位置不对，后面调代码怎么调都别扭。

先说高度。摄像头装得越高，视野越宽，能看到更远的赛道，但代价是近处的赛道在画面里变小了，近端分辨率变差，转向对近距离误差的感受变钝。装得太低，近处看得清楚，但远处完全看不见，过弯就像瞎子摸路。我自己的经验是：高度8-12厘米，俯仰角向下倾斜30度左右。这样画面下半部分是车前20厘米内的近距离赛道，上半部分是30厘米外的远方赛道，两者兼顾。

再强调一点：摄像头一定要居中装在车身的纵向中轴线上，歪一点都不行。我调试时遇到过一台车，摄像头装偏了5毫米，结果车在直道上走得也直，但总感觉车身是斜的，像螃蟹一样横着走。排查了半天，最后发现是图像里的“对称中心”和车身实际中心不重合。你用ROI框定中线的时候，参考基准是图像的中心列，但图像中心不等于车身中心，这个系统误差会让车始终带着一个固定的方向偏差。解决办法有俩：一是物理上把摄像头对准，二是在代码里做一个“中心列偏移”校准：

# 摄像头物理安装偏了，在代码里修正偏移量 img_center_x = 80 - CAMERA_OFFSET_X # 比如偏右5像素，就减5 err = line.x2() - img_center_x

5.3 跑车调试实录：三种典型故障的排查过程

这里分享几个真实车跑起来之后遇到的典型故障，按排查链路写出来，方便你照着查。

故障一：直道走不直，车身像烂泥一样左一拐右一拐。

排查顺序：先用串口把OpenMV发出来的err值打出来看——发现图像处理输出的误差信号在小范围抖动（±5像素以内）。这说明图像处理本身不稳定，二值化结果在抖动。再看二值化画面，发现赛道边缘有锯齿状闪烁。原因找到了——自动曝光（AE）在作怪。OpenMV默认会自动调整曝光时间，车在室内日光灯下走，光线有细微闪烁，自动曝光跟着一起抖动，导致二值化阈值也跟着抖。

解决方式很简单：固定曝光参数：

sensor.set_auto_exposure(False, exposure_us=20000) sensor.set_auto_whitebal(False)

锁定曝光和白平衡之后，图像信号稳定了，误差输出也稳了，车走直了。

故障二：在弯道里车突然朝错误方向打方向，然后又猛拉回来。

排查发现画面里出现了“第二个白色区域”——原来是赛道旁边一张白色A4纸被误识别成赛道了。因为我在做get_regression之前没有限制ROI，全图白色区域都被算进去了。解决方法是把ROI框定到赛道所在的梯形区域内，并加了面积过滤。如果你遇到类似问题，一定要检查是不是画面上方“无关白色”太多了。

故障三：连续跑三圈之后，车越来越慢，最后停下不动。

这个太经典了，几乎所有人都会遇到。排查下来发现是锂电池电压从12.6V降到了10.5V左右，电机驱动模块虽然还有电，但电流不够了，舵机或者电机响应变慢。你调好的PID参数是在满电状态下调的，电压一掉，实际输出扭矩不够，形同于“控制器增益变了”。解决思路是给速度环加一个电压补偿：实时采集电池电压，电压低于阈值时给PWM基础值加一个偏移。严谨一点的做法是用电压表标定“不同电压下的PWM-实际转速”曲线，但日常规模的项目里，一个线性补偿公式就够了。

6. 参数调节的顺序和实验验收方法：怎么才算调好了

编码调通了、硬件也稳了，最后一个问题：你怎么知道这辆车算是“设计完成”了？总不能是“它走了两圈没翻车”就算胜利吧。我提供一套我常用的调节和验收步骤，你可以直接抄作业。

6.1 分阶段调车：先稳后快，先走直线再过弯

我调循迹车的顺序从来不是“一上来就丢到完整赛道上跑”。那样出了问题根本不知道是图像问题、控制问题还是机械问题。我的节奏是：

第一阶段：定速测试。先把PWM固定在一个较低的值（比如20%占空比），不要做任何自动控制。测试车能否沿一个方向直线开出1米以上。做不到就调机械，检查轮子是否卡、电机转速是否一致。这个阶段过了，说明底层驱动没问题。

第二阶段：离线误差观察。把车拿在手里，对着赛道不同位置，看 OpenMV 发出来的误差值是否符合直觉——赛道在左边，误差负；赛道在右边，误差正；直线赛道误差接近零。这个阶段是验证“感知”是否正确的关键步骤，很多人跳过了，结果后面全乱了。

第三阶段：低速PID闭环。速度依然设低，只加P控制，让车能走上赛道。注意记录：直道是否回摆？弯道是否冲出去？回摆就加D，冲出去就加大P或者降低速度。目标只是“低速下完整跑完一圈不掉线”。

第四阶段：速度提升和预瞄调优。速度提上来之后，开始加入远、近端偏差加权，让车提前对弯道做出反应。这个阶段你会发现速度提升到某个值之后，控制开始不稳定。记录这个“临界速度”，如果没有硬性要求，就保持在这个速度以下；如果必须更快，考虑调整预瞄权重和PID参数。

6.2 验收指标与数据记录：别靠感觉调参

具体验收可以用几个硬指标：

• 完整跑圈成功率：连续跑10圈，至少8圈不掉线、不跑出赛道。
• 最大过弯速度：在一个固定半径弯道（比如半径30cm的直角弯）上，立定加速能通过的最大PWM占空比。
• 直道偏移峰峰值：在5米直道上跑完，记录偏差误差的最大最小值，目标要求直道偏移峰峰值不大于车身宽度的1/4。
• 响应时间：用手挡住摄像头前方赛道1秒，再放开，观察车恢复到正常状态的时间。通常要求不超过2秒。

每次调参，建议记录一组数据：P参数、D参数、预瞄权重、测试速度、直道效果、过弯效果。不要靠感觉“嗯这次好点了”。人的感觉会骗人，数据不会。

6.3 光照环境变化后怎么快速恢复参数

“昨天还好好的，今天搬到另一个教室就全乱了。”这句话我听了不下二十遍。视觉循迹天然受光照影响，这是物理规律，你躲不开，只能应对。

应对的核心方法是在代码里加入“动态阈值更新”的机制。最简单的版本：每次跑之前，让OpenMV先对赛道区域拍一帧图像，自动从画面中采样几个像素点的LAB值，自动生成一组二值化阈值。这个思路十几行代码就能实现：

def auto_threshold(): img = sensor.snapshot() # 手动指定赛道区域ROI，采样白色的LAB值 hist = img.get_histogram(roi=TRACK_ROI) # 用直方图的峰值近似赛道颜色中心 # 然后根据中心值上下浮动作为阈值

不用做得多智能，能把阈值从“手动写死”变成“开机自动校准一次”，就足够应对大部分换场地的情况了。进阶玩法是用多组阈值（比如前后不同ROI区域各自用各自的阈值），这个看你赛道的复杂度来定。

7. 给正在做这个课题的人几个实在的建议

聊到这儿，关于机器视觉循迹小车的核心链路已经讲得差不多了。最后想用千八百字聊聊那些“课程论文里不会写、答辩老师不会问”的真实体会。

第一个体会：千万不要在“完成度不足”的时候去追求“智能化”。我见过不少人，课设题目是循迹小车，结果做着做着就开始往里面加人脸识别、加语音播报、加手机APP遥控，加了三天发现自己连直线都走不稳。先把“循迹”二字做扎实，再谈其他。循迹是“花”，其他是“锦上添花”，花没开好，添再多锦也没用。

第二个体会：文档和代码注释是给未来的自己看的。调PID调了三个小时，终于找到一个能用的参数组，如果你不把这个参数记录下来，不把当时的光照条件、速度档位、赛道材质写清楚，明天你再来调，大概率还得重新走一遍弯路。我的习惯是每辆车配一个“调车日志”，记录每一次参数修改的前后效果。看着是笨功夫，实际上省钱省时间。

第三个体会：遇到问题先怀疑“感知”，再怀疑“控制”。这个问题真的是无数次血泪换来的。车跑飞了，多数人第一反应是“PID没调好”。但实际上，100次里面有70次是图像处理那边出了变故：二值化阈值漂了、噪点没滤掉、ROI框到了赛道外。先打开IDE看清楚摄像头到底看到了什么、发出来的误差值是什么，再动控制参数。眼睛没看清，手再快也是瞎打方向。

做这类系统，真正让你成长的不是最终那辆小车跑得多稳，而是你在“为什么它会往左偏”这种问题上的思考深度。视觉、控制、硬件，三个方向串起来，你会慢慢形成一个“系统工程师”的思维习惯——这套思维以后不管是做更高级的无人车、还是做工业视觉设备，都吃香。把这些事想明白，你就已经把“基于机器视觉的循迹小车”这门课真正吃透了。