视觉巡线小车这东西，圈里玩过的人不少，但真正把“为什么这么做”讲清楚的文章不多。我手上这个项目是用OpenMV做视觉识别、STM32做底层控制的经典组合，跑起来之后发现坑主要在联调和参数整定上，所以这篇总结不打算罗列代码，而是把方案选型、硬件连接、软件逻辑、PID整定和排查经验一条线讲透。适合正在做巡线车、准备参加智能车竞赛、或者想入门机器视觉+单片机协同工作的同学参考。
1. 整体方案设计：为什么是OpenMV + STM32
1.1 这个组合的优势在哪
视觉巡线的本质是“看见线→算出偏差→控制电机修正方向”。这个流程听起来简单，但实际拆开就涉及图像采集、图像处理、偏差计算、运动控制、电机驱动等多个环节。如果全部压在一个主控上做，性能和开发效率都会出问题。
选OpenMV处理视觉、STM32负责控制，核心原因是两者能力高度互补。OpenMV集成了摄像头、图像传感器和MicroPython解释器，几行代码就能完成色块识别、线段检测，开发效率极高；而STM32在电机控制、定时器PWM输出、中断响应方面是强项，实时性有保障。两者通过串口通信各司其职，比单芯片方案更容易调试，也更贴近真实产品的分层架构。
我还对比过直接用树莓派做的方案。树莓派性能强很多，但功耗大、启动慢、需要跑Linux系统，对巡线小车这种“开机即跑”的场景来说属于杀鸡用牛刀。OpenMV启动时间在秒级，整机功耗低，更适合嵌入式场景。
1.2 系统架构与数据流向
这辆小车的整体架构分三部分，正好对应了“感知—决策—执行”的经典链路。
感知层是OpenMV。它负责采集地面图像，通过阈值分割提取赛道中的黑线或白线，然后计算线相对于画面中心的偏差值。这个偏差值是整个控制环路的核心输入。
决策层是STM32。它通过串口接收OpenMV发送的偏差数据包，解析后用PID控制器计算左右电机的转速差值，输出对应的PWM占空比。
执行层是TB6612电机驱动模块和直流减速电机。STM32的PWM信号经过驱动模块放大后驱动电机转动，两轮差速实现转向。
具体的数据流是：OpenMV → 串口(偏差值) → STM32校验解析 → PID计算 → PWM输出 → 电机转动。这个链路每一步都有讲究，后面我会拆开细说。
1.3 主控芯片选型考量
很多人问STM32选哪个型号够用。我这次用的是STM32F103C8T6，也就是大家常说的“蓝板”，性价比很高，主频72MHz，资源上看：
- 3路USART，一路给OpenMV通信，还能留一路做调试日志打印
- 多路定时器带PWM输出，两路PWM控制左右电机绰绰有余
- 丰富的GPIO，控制编码器、指示灯都不紧张
选型的时候不用盲目追求高配，F103对于巡线小车这个算力需求完全足够。如果你想在这个项目上叠加更复杂的算法，比如卡尔曼滤波、惯性导航，那就建议上F405或者F427了。
2. 硬件搭建与关键模块细节
2.1 OpenMV的安装方式与镜头选型
OpenMV的安装位置和角度，直接影响巡线算法的复杂度和稳定性。我踩过坑，先说结论：镜头正对地面、安装高度距地面15到20厘米左右，效果最好。
开始的时候我把OpenMV装成45度俯角，想着能看到更远的路况。结果发现图像畸变严重，远处的线和近处的线宽度差异巨大，阈值分割后ROI区域内的线宽忽粗忽细，给后续偏差计算带来很大干扰。改成垂直朝下之后，画面就是一个稳定俯视图，线的宽度在整个视野内保持一致，处理逻辑瞬间简洁了。
镜头选型方面，如果场地跑道比较宽，用默认的2.8mm广角镜头就行；如果跑道很窄、想要更大的检测视野，可以考虑更换广角镜头。不过我建议新手先用默认镜头调试通整个流程，再考虑改装。
2.2 电机驱动模块：TB6612为什么比L298N香
电机驱动我用的是TB6612FNG。对比常见的L298N，TB6612体积小很多，内部是MOSFET H桥结构，导通压降低，发热小，允许通过的峰值电流也有1.2A，驱动普通小型直流减速电机绰绰有余。
接线方式和L298N类似，但有个细节需要特别留意：TB6612的逻辑电源和电机电源是分开的。VM接电池正极（电机电源），VCC接3.3V或5V（逻辑电源，给芯片内部逻辑供电），GND需要和STM32共地。如果VCC不接，芯片逻辑不工作，PWM信号进去也没反应。
驱动小车的电机我用的是一款1:48的直流减速电机，额定电压6V，空载转速大概300转每分钟。配合直径65mm的轮子，整车速度在0到1.5米每秒之间可调，跑普通赛道足够。
2.3 电源系统设计：为什么必须分两路供电
电源系统是我在这次项目中花时间最多的地方之一。小车用的是2节18650锂电池串联，标称电压7.4V，充满电8.4V。一开始我图省事，直接一路电源给OpenMV、电机驱动和STM32同时供电，结果电机一转，屏幕上OpenMV画面就抖，严重的时候还重启。
排查之后发现问题出在电机启动电流导致的电压跌落上。电机启动瞬间电流可达工作电流的数倍，线路内阻和电池内阻上的压降会让母线电压瞬间跌落十几V以下，而这个电压恰恰又是逻辑电路的供电来源，一跌就复位。
正确做法是分层供电：
- 电池母线的7.4V直接给电机驱动模块VM供电
- 经过降压模块输出5V给OpenMV供电
- 经过AMS1117-3.3降压给STM32供电
这样电机电流波动被隔在电源树的前级，逻辑电路的供电稳定性大幅提升。实测下来，即使电机堵转，OpenMV和STM32也不再复位了。
注意：降压模块的输入输出电容不要省，输入100uF电解电容加0.1uF陶瓷电容，输出同样加上，能有效抑制开关噪声。
2.4 底盘结构与传感器扩展
底盘我用的是常见的亚克力两轮差速底盘，后面带一个万向轮。这个万向轮很有讲究，必须选那种带弹簧、转动灵活的，否则转弯时车身会抖动，影响OpenMV采集图像的质量。如果万向轮转动不顺畅，小车转弯会像“甩尾”一样，巡线稳定性大打折扣。
另外我预留了编码器接口，后期想上闭环速度控制的话，可以直接把带编码器的电机接入定时器编码器模式。虽然这次巡线用的是开环+位置式PID，但如果赛道复杂、要求速度快，闭环是必须的。这个后面会再提及。
3. 软件逻辑拆分：从图像到控制的完整链路
3.1 OpenMV端的巡线算法
OpenMV端是纯Python写逻辑，IDE可以直接连接摄像头调试，实时查看每一帧的处理效果。巡线算法的核心步骤：
第一，采集图像后设置ROI，只保留靠近车头的一段区域，一般是画面的下半部分。这样做有两个好处：一是排除远处复杂背景的干扰；二是减少处理像素数量，提升帧率。
然后用find_blobs函数查找目标色块。比如黑线赛道，就把THRESHOLD设置为(0, 40)附近，提取亮度较低的像素区域。OpenMV官方的阈值编辑器非常好用，可以实时调整阈值并看到二值化效果，我建议所有初学者都先用这个工具把阈值调到“目标线为白色、其他区域为黑色”的效果，再去写代码。
最关键的一步是计算偏差。find_blobs返回色块对象的cx坐标——也就是色块中心的横坐标，而画面的中心横坐标是img.width() // 2。两者之差就是线相对于画面中心的偏差。
但这里有个大坑：直接用cx - width/2当偏差，在小车车身已经明显偏离赛道时，这个值可能会突变。因为当车身偏到一定程度，视野中的线已经不在画面里了，cx会突然跳到另一条干扰线或者消失。所以我在实际代码里做了处理：如果找不到色块，就返回一个“丢失”标志，STM32收到后执行原地寻线逻辑（小角度来回摆动搜索），而不是盲目按上一次的偏差继续跑。
完整巡线代码的核心部分大概是这样的：
import sensor, image, time, math from pyb import UART uart = UART(3, 115200) sensor.reset() sensor.set_pixformat(sensor.GRAYSCALE) sensor.set_framesize(sensor.QQVGA) # 160x120 sensor.skip_frames(time=2000) THRESHOLD = (0, 40) ROI = (0, 40, 160, 80) # 只取画面下半部分 while True: img = sensor.snapshot() blobs = img.find_blobs([THRESHOLD], roi=ROI, pixels_threshold=5, area_threshold=5, merge=True) if blobs: # 取最大色块作为目标线 max_blob = max(blobs, key=lambda b: b.area()) cx = max_blob.cx() err = cx - img.width() // 2 # 偏差，左负右正 # 归一化到 -100 ~ +100 err_norm = int(err / (img.width() // 2) * 100) data = bytearray([0xAA, 0x01, err_norm & 0xFF, 0xFF, 0x55]) uart.write(data) else: # 丢线标志，err = 127 data = bytearray([0xAA, 0x01, 0x7F, 0xFF, 0x55]) uart.write(data)3.2 STM32端串口通信协议设计
OpenMV通过串口把偏差值发到STM32，但串口通信起来有个经典问题：如果只发一个字节或者裸发数据，接收方根本不知道什么时候是数据开头、什么时候是结束。所以我在这一版里设计了一个简单的帧协议。
帧格式是：
| 帧头 | 数据类型 | 数据 | 保留 | 帧尾 |
|---|---|---|---|---|
| 0xAA | 0x01 | err_norm | 0xFF | 0x55 |
STM32端用串口中断接收，再通过状态机解析。我不用中断里做PID计算（会拖慢中断响应），而是中断只负责把数据放进缓冲区，主循环里再解析和处理。
状态机的逻辑：
- 初始状态等待帧头0xAA
- 收到0xAA后进入数据类型状态
- 依次接收数据、保留、帧尾，全部对齐后校验帧尾0x55
- 校验通过才更新偏差值，否则丢弃整帧等待下一个帧头
这样处理下来，即使偶尔丢一个字节，下一帧也能自动恢复同步，整个系统非常健壮。
3.3 PID控制：巡线小车的灵魂
偏差算出来之后，怎么把它转化成左右电机的转速差？这就是PID控制器的工作。
巡线小车我推荐用位置式PD控制，也就是只用比例和微分环节。I项积分在小车巡线场景里大多数时候是帮倒忙的——因为赛道是动态变化的目标，旧误差的积分反而会让系统反应迟钝，甚至引起超调震荡。
控制量计算公式：
output = Kp * error + Kd * (error - last_error)这个output是一个差速量，叠加到基础速度上：
- 左电机PWM = base_speed - output
- 右电机PWM = base_speed + output
比如base_speed = 60（占空比60%），如果偏差为+30，Kp=2，那么output=60，此时左轮PWM=0，右轮PWM满转，小车会快速右转把线拉回中心。Kd项则起到“阻尼”的作用，当偏差变化剧烈时，提前减小输出，防止小车左右晃动。
PWM频率我设置为10kHz，为了避开音频范围，电机也不会发出刺耳的啸叫声。很多新手用1kHz，电机响得跟报警器一样，而且低速时扭矩明显不足。建议把定时器时基设到10kHz以上。
3.4 STM32主循环的框架
STM32端主循环的逻辑可以简化成：
while (1) { if (flag_received) { flag_received = 0; int16_t pid_output = PID_Calculate(err); Motor_SetSpeed(base - pid_output, base + pid_output); } // 如果一定时间内没收到数据，电机停止，保证安全 if (HAL_GetTick() - last_rx_tick > 200) { Motor_SetSpeed(0, 0); } }这里有个安全设计：如果超过200ms没有收到OpenMV的数据，就自动停车。这个保护逻辑在我调试的时候救过好几次——有一次OpenMV的MicroUSB线松了，OpenMV直接断电停止发送数据，要不是有超时停车逻辑，小车就直接冲下桌子了。
4. 联调过程、PID参数整定与问题排查
4.1 联调第一步：先确认通信链路
整个系统写完之后，不要急着下地跑。我建议按三步走：
第一步，单独测试OpenMV。把OpenMV连上电脑，用IDE运行巡线脚本，串口助手接上OpenMV的串口输出，确认能收到稳定、连续的数据帧。
第二步，单独测试STM32控制逻辑。用一个上位机模拟串口发送偏差帧，观察电机是否按预期转动，转的方向是否正确。检测时用一个USB转TTL模块连接STM32的串口即可。
第三步，整体联调。OpenMV和STM32物理连接后，在赛道上手动抬起小车移动位置，观察电机轮子的转向是否始终朝向赛道中心。这里有90%的几率会发现方向反了——比如线在左边，按逻辑应该左轮减速右轮加速向左转，但实际却向右转。解决办法很简单：把电机两根输出线对调，或者在代码里把PID输出取反。代码取反更省事。
4.2 PID参数整定：从震荡到稳定的实战流程
PID整定是个“经验活”，但我有相对标准的流程可以分享。
初始Kp不要设太大，先设为0.5，Kd设为0。这时把小车放在直道上启动，观察它会怎么走。如果它能走一小段然后偏离赛道，说明有基础的控制能力，可以慢慢加Kp。
Kp逐渐加大的过程中，你会观察到小车开始出现左右摆动的现象，振荡频率越来越快。当Kp加大到小车开始明显高频抖动时，就退回大概20%的Kp值，这就是一个比较合适的P值。
021D参数用来解决高频抖动。我调试时Kp定在2.0，小车转弯反应很快但车身一直抖，加了Kd=0.5之后，抖动明显被抑制。继续加到1.0之后，直线段车身变得非常稳定，转弯也能保持平滑。但Kd不能加太大，否则转向响应变钝，过弯时会出现“跟不上线”的情况。
I项，我在最终代码里留了注释但没启用。如果你的小车有固定负载、或者电机空载与带载差异大导致有稳态静差，再考虑加I，积分限幅设在±20比较好，防止积分饱和。巡线小车对稳态误差其实没那么敏感，I项加不好反而容易在弯道处“冲出赛道”。
4.3 常见问题与排查技巧实录
根据我这次项目踩坑的经验，整理几个高频问题和应对方案：
问题一：OpenMV画面卡顿，帧率低
先确认分辨率是否合理，QQVGA（160x120）是最佳平衡点，VGA分辨率对于巡线场景完全没有必要。其次检查ROI是否设置，如果全图处理，帧率会掉到15帧以下，控制周期拉长后转弯响应会变得迟钝。我在最终版本里大约能跑到35到40帧每秒，控制效果明显比20帧好很多。
问题二：串口数据老是乱码或者接收不完整
查三件事：第一，共地没？OpenMV和STM32的GND必须连在一起，否则TTL电平没有参考地，数据必乱。第二，波特率是否一致。OpenMV的UART初始化是115200，STM32串口配置也必须115200。第三，帧协议是否健壮。如果没有帧头帧尾校验，单纯发一个字节，串口线稍微有点干扰就错位。
问题三：PID调好后直道稳定，弯道冲出赛道
经典问题。原因通常是基础速度设置的太高，导致弯道处即使PID输出已经饱和到100%差速，转向力度依然不够。解决办法有两个：一是降低基础速度；二是做速度自适应，根据偏差大小动态调整基础速度——偏差大时主动降速，偏差小时恢复高速。
我还实现了一个简易的模糊控制策略：base_speed = 70 - abs(err) * 0.3，也就是说偏差越大，基础速度越低，这时PID差速的占比会更大，转向更灵活。这个策略实测非常有用，过急弯基本不会冲出赛道。
问题四：环境光变化导致阈值失效
这个问题在白天和夜晚交界时最明显。早上调的阈值，到了下午阳光变强，黑线的灰度值变了，find_blobs就识别不到线了。
解决办法有几个方向：最稳妥的是用OpenMV的自动曝光和自动白平衡，但要在初始化的时候调用sensor.set_auto_whitebal(True)和sensor.set_auto_exposure(True)，同时锁定色温。或者固定场景，用灰阶读取多次取平均来动态计算阈值，再结合自动曝光函数img.get_statistics()做自适应阈值。我在最终代码里做了一版动态阈值：根据img.get_statistics().mean()自动调整色块阈值范围，能应对大部分室内光照变化。
4.4 关于距离控制和更多拓展
巡线做完之后，我顺手给小车加了个超声波避障模块（HC-SR04），接在STM32的另外一组GPIO和定时器上，用输入捕获方式测量回波脉宽，这样在小车巡线时如果检测到前方障碍物，就进入刹车状态。这个扩展非常快，完全不干扰巡线逻辑。
如果想让巡线小车更“聪明”，还可以在OpenMV端做十字路口识别、斑马线停车、视觉标签识别等。OpenMV的find_qrcodes、find_apriltags都是现成API，识别到指定标签后通过串口发送特殊指令，STM32执行对应的状态切换。我在巡线基础上加了一个二维码站点识别，小车到指定位置后自动停车并且鸣叫提示，这个组合非常容易实现。
5. 几个容易被忽略的小细节
5.1 机械结构比想象中更重要
很多人把精力全部放在代码上，忽略了机械结构的稳定性。实际上螺丝松动导致轮子抖动、万向轮卡顿导致转向不灵活，这些问题反映到巡线效果上，就是“PID怎么调都调不好”。我的经验是：每次调试前先检查轮子有没有松动、传感器有没有偏移，机械状态确认后再动代码。
5.2 调试输出要多留一手
就是STLINK或者黑板，给STM32留一路调试串口，在代码里加一个日志输出功能，把接收到的偏差、PID输出、PWM占空比都打印出来。最初觉得麻烦，后来发现这几乎是排查问题最快的手段。例如，如果你不确定是通信问题还是PID问题，看一眼日志就明白了。
5.3 关于OpenMV的帧率优化
巡线的帧率直接影响控制周期，帧率越高，控制越平顺。除了降低分辨率和ROI，图像处理还有个优化点：二值化时可以先用img.binary()把灰度图转成黑白图再找色块，因为find_blobs在二值图像上查找速度比灰度图快不少。另外，merge=True参数能合并相邻色块，避免一条线被拆成多段导致偏差抖动。
个人在做这个项目的过程中最深的体会是：视觉巡线小车虽然入门门槛不算高，但它把单片机、传感器、图像处理、控制算法、机械结构全部串联起来，是一个综合度极高的练手项目。做完一辆，你对整个嵌入式系统的理解会上一个台阶。如果有的选，建议不要用网上现成的成品方案，从选型到焊接再到调参全部自己走一遍，踩过的坑才是真正学到的东西。
