STM32循迹小车实战：灰度传感器与OpenMV权重融合方案

简介：基于STM32的灰度+OpenMV循迹小车项目资源，面向电子设计竞赛、工程训练赛及智能车入门的初学者。资料完整给出车体结构、驱动电路与程序设计的实现框架，并针对直道、弯道、十字路口等不同赛道场景，说明了灰度传感器阈值输出与OpenMV视觉权重判断的协同策略，适合从零搭建稳定可靠的自动循迹方案。压缩包共106个文件、总大小约1.72MB，核心为C语言工程：23个C源文件与60个头文件覆盖定时器、系统时钟、Flash等HAL库底层驱动；同时附带Python脚本、CubeMX工程配置、Keil项目文件、可直接烧录的HEX固件，以及PDF、Markdown、TXT等说明文档，并加入启动汇编文件与传感器图像，便于代码阅读、编译调试与二次开发。目前已有13562人学习下载，目录结构清晰，在同类初学项目中具有较高人气。通过逐模块阅读和对照实验，可系统掌握从传感器信号采集、灰度与视觉权重融合判断到电机PWM闭环输出的完整流程，同时积累中断优先级配置、串口调试、阈值整定等实战经验，大幅缩短从原理搭建到小车实际跑通的时间。

1. 项目概述：这套循迹小车为什么值得你做

做循迹小车一直是嵌入式入门最经典的实战项目，但很多人做到一半就卡住了：纯灰度方案过不了十字弯、断线区域一冲就飞，OpenMV单独跑又存在帧率低和光照敏感的问题。我这次做的这版STM32循迹小车，核心思路是灰度传感器做主定位、OpenMV做视觉纠正，最后在STM32端用权重判断融合两路信号，实际跑下来在普通白底黑线的赛道上可以稳定过直角、十字和断线区域。

如果你正在备赛智能车、电子设计竞赛，或者单纯想把手上的STM32开发板玩出点真东西，这篇内容能帮你少走不少弯路。全文会按硬件选型、灰度处理、OpenMV巡线、通信协议、PID控制、联调排坑六个部分展开，确保你照着搭也能跑起来。

2. 为什么放弃单传感器方案，改做灰度+OpenMV融合

2.1 灰度传感器单独方案的天花板

市面上最常见的循迹车是三四路TCRT5000灰度模块，靠黑线和白底的反射率差异输出高低电平。这玩意儿优点很实在：响应快，基本无延迟；逻辑简单，读GPIO就能用；成本低，几块钱一个。

但它的短板也很明显。第一，赛道稍微复杂一点就傻眼——十字路口四路全黑，直行还是转弯全靠猜；第二，断线区域整组传感器扫不到黑线，小车会直接按最后状态冲出去；第三，灰度传感器看不出赛道走向趋势，只能判断当前这一瞬的线在哪，没法预判前面的弯道半径。做过竞赛地图的人应该都懂，地图设计里最恶心的就是急弯和断线组合，纯灰度车大概率在这里翻车。

2.2 OpenMV视觉方案的补充价值

OpenMV本质是一个带摄像头和MicroPython解释器的嵌入式视觉模块，能实时采集图像并做色块识别。它对巡线的核心贡献在于：能一次看到几十厘米外的赛道走向，通过帧图像判断出黑线的位置偏移量和弯道趋势，这是灰度传感器完全不具备的预判能力。

但OpenMV单独做循迹也有致命问题。一是帧率不够，普通场景跑个三四十帧就是极限，车速稍微拉起来画面就卡顿；二是光照极度敏感，同一个场地上午下午光线不同，二值化阈值经常要重新调；三是成本偏高，一块官方OpenMV CAM H7就要几百块，用一片做视觉主控做坏了心疼。而且MicroPython的解释执行效率比C裸机差不少，纯视觉跑高速很容易处理不过来。

2.3 权重融合的实际收益

所以我的方案就是把两者各取所长：灰度传感器做近场精确跟踪，它的响应速度够快，误差小；OpenMV做远场趋势判断，提供赛道走向和异常区域预判。最终在STM32端给两种传感器分配不同权重——近场灰度权重高、紧急避障时权重高，OpenMV起修正和预判作用。

这套思路实际跑下来，最直接的收益体现在三个场景：过十字弯时灰度信号乱掉，OpenMV的线位置权重接管方向；断线区域灰度全丢，OpenMV根据记忆线方向维持前进；急弯处灰度只看到局部弯道，OpenMV提前给出转向趋势，让转向动作更平滑。这套方案做下来，本质上是用低成本传感器组合模拟了更高阶的视觉循迹效果，关键逻辑可以在STM32标准的HAL库工程里实现，不需要什么高深算法，但每一步都有可解释的工程理由。

3. 硬件选型与接线：怎么搭一个不踩坑的底盘

3.1 主控、传感器、电机驱动选型清单

先按我实际使用的配置列一个清单，都是淘宝能直接买到的主流型号：

这里特别说下电机驱动的选择。很多新手图便宜买L298N，那个模块压降大、发热厉害，而且体积和重量都不小，放在小车上对重心很不友好。TB6612FNG的MOS管压降只有零点几伏，体积小，两路电机带PWM调速完全够用，价格也就十几块钱。

3.2 走线布局与接线细节

接线这块我走过的弯路比较多，给你整理一套我验证过的接法：

• STM32供电：用AMS1117-5.0从电池降压后给板子5V，再把板载稳压的3.3V供给OpenMV
• 灰度模块：VCC接5V，GND共地，OUT引脚接STM32的GPIO输入（四路分别接PA0~PA3，带ADC功能也可以）
• OpenMV：VIN接3.3V或5V（具体看你模块规格），TX接STM32的PA10（USART1_RX），RX接PA9（USART1_TX），GND共地
• TB6612：PWMA/PWMB接定时器PWM输出脚，AIN1/AIN2和BIN1/BIN2接普通GPIO，VM接电池正极，VCC接5V逻辑电源

共地这个细节必须强调一下。我第一次接的时候偷懒没把电机驱动的GND和STM32的GND连在一起，结果电机一转，串口数据就乱码，OpenMV收到的数据全是错的，排查了很久。后来把地线全部接到一起，再用粗一点的杜邦线连接电池负极和驱动板GND，现象立刻消失了。

灰度传感器的安装位置也直接关系到循迹效果。我是把四路灰度模块装在车头前方约2cm处，间距18mm左右，这样在标准15~20mm宽的赛道黑线上刚好覆盖左右余量。模块高度调成距离地面约1cm，太高红外反射信号弱容易误判，太低遇到轻微颠簸就会蹭到地面。装好后用一字螺丝刀调节模块上的电位器，让它在白底上输出低电平、黑线上输出高电平，这套阈值对了后面的事才好办。

4. 灰度传感器部分：阈值处理与去抖逻辑

4.1 数字量阈值与模拟量阈值的取舍

TCRT5000灰度模块一般有两种输出模式：数字量（比较器输出0/1）和模拟量（输出电压随反射强度变化）。数字量方式接线最简单，GPIO直接读电平，但阈值在模块上用电位器调死了，一旦环境光变化或者赛道底色不均匀就得重新拧电位器。

模拟量方式更好用也更灵活。把OUT引脚接到STM32的ADC输入，实时采集电压值，在代码里动态设置阈值。我的做法是上电时先让小车静止在赛道上，连续采集若干次白底和黑底的ADC值，取二者的中间值作为运行时阈值，这样不用每次手动调电位器，环境光变化时也能自适应。

这里贴一段我在标准库下写的灰度读取与状态判定代码，供参考：

uint16_t gray_adc[4]; // 四路灰度ADC缓存 uint8_t gray_digital[4]; // 阈值判定后的0/1状态，1代表压线 #define GRAY_THRESHOLD 1800 // 典型值，实际需根据标定结果修改 void Gray_ADC_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; ADC_InitTypeDef ADC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN; GPIO_Init(GPIOA, &GPIO_InitStructure); ADC_DeInit(ADC1); ADC_InitStructure.ADC_Mode = ADC_Mode_Independent; ADC_InitStructure.ADC_ScanConvMode = ENABLE; // 扫描模式 ADC_InitStructure.ADC_ContinuousConvMode = ENABLE; ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None; ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right; ADC_InitStructure.ADC_NbrOfChannel = 4; ADC_Init(ADC1, &ADC_InitStructure); ADC_RegularChannelConfig(ADC1, ADC_Channel_0, 1, ADC_SampleTime_55Cycles5); ADC_RegularChannelConfig(ADC1, ADC_Channel_1, 2, ADC_SampleTime_55Cycles5); ADC_RegularChannelConfig(ADC1, ADC_Channel_2, 3, ADC_SampleTime_55Cycles5); ADC_RegularChannelConfig(ADC1, ADC_Channel_3, 4, ADC_SampleTime_55Cycles5); ADC_DMACmd(ADC1, ENABLE); // 配合DMA使用，效率高很多 ADC_Cmd(ADC1, ENABLE); }

读完ADC之后不能直接用原始值，我建议加两个处理步骤：一是滑动平均滤波，取最近5次采样的平均值，平滑掉地面反光抖动；二是一个简单的去抖状态机，连续两次检测到同一状态才更新输出，避免小车在黑白交界处状态跳变。

4.2 灰度数据如何转换成偏差量

四路灰度读数转偏差量的方法有两种思路。简单粗暴的做法是查表法：把四路状态组合映射成左偏、右偏、居中、全黑（十字）、全白（出线）这些离散状态。这种方案逻辑清晰，但只能给出方向级别的大偏差，控制精度有限。

更平滑的做法是加权中心法。给每一路灰度分配一个位置权重，比如从左到右依次是-3、-1、1、3，然后计算加权和除以有效路的数量，得到一个连续的偏差值。这个偏差值可以直接送进后面的PID控制器，反应更细腻。

这个思路和OpenMV端权重判断的核心思想是一样的，你可以理解为灰度端也在做一次权重计算：有效传感器状态为1的才能参与加权，没压线的路权重自动清零。我在实际代码里就是这样实现的，效果比查表法好很多，尤其是在过弯的时候能明显感觉到转向更线性，不会一顿一顿地修正。

5. OpenMV巡线程序与权重判断：视觉端怎么做

5.1 OpenMV端的图像二值化与巡线逻辑

OpenMV端做的第一件事是图像预处理。以黑线白底赛道为例，先截取画面的下部感兴趣区域（ROI），因为这部分离车头最近，最可靠。然后转灰度图，用threshold二值化把黑线变成白色区域、底色变成黑色，再用find_blobs函数找出黑白分割后的白色色块。

这里有个很关键的参数：用find_blobs找线时，要把blob的pixels面积设一个最小值，过滤掉噪点。我的经验值是pixels大于200才认为是有效线，否则丢弃。这能有效避免地面上小污渍或者反光点被误判成赛道线。另外还要限制blob的宽度，如果宽度明显大于赛道线宽度（比如大于50像素），大概率是反光造成的异常区，这种情况下要降权或者直接忽略。

当OpenMV找到有效线时，会给出目标色块的中心x坐标cx。正常情况下，cx应该落在画面中间区域。如果cx偏左，说明黑线在车头左侧，小车需要左转；反之则需要右转。OpenMV返回的这个cx值本质就是一种原始的线位置量，但直接拿它当控制量还不够稳，这就是接下来权重判断要解决的问题。

5.2 权重判断：如何把图像坐标变成控制可信度

我在OpenMV端做权重判断时，核心不是只取cx，而是把整个画面按列切成若干个区域，每个区域分配一个权重系数，然后统计黑线像素在每一列的出现情况，计算加权和得到线位置的加权偏移量。这样一个简单的列权重数组就能表达“画面越靠左的线越需要小车大幅左转”的物理含义。

权重数组的设计决定了转向的敏感度。我的做法是左右两侧的权重绝对值大、中间区域权重绝对值小，这样即使线位置在画面中心附近有些抖动，加权偏移量也不会产生剧烈波动。你可以把权重数组想象成人为给画面不同区域分配了“紧急程度”：偏离中心越远，紧急度越高，控制器收到的转向信号也越强。

OpenMV端还同时完成一个任务：判断前方是否进入断线区或急弯。如果连续若干帧找不到有效blob，就说明黑线消失了，这时候OpenMV发送一个特殊的“断线帧”标志，STM32收到后进入开环保持状态，不再尝试纠正方向，而是按上一帧的转向趋势继续前进一段距离。这个动作对比赛很有用，能让小车快速冲过断线区域而不甩尾。

配套的OpenMV代码大致长这样：

import sensor, image, time from pyb import UART sensor.reset() sensor.set_pixformat(sensor.GRAYSCALE) sensor.set_framesize(sensor.QQVGA) sensor.skip_frames(30) uart = UART(3, 115200) uart.init(115200, bits=8, parity=None, stop=1) # 列权重数组，越靠两侧权重绝对值越大 weights = [-4, -3, -2, -1, 0, 1, 2, 3, 4] ROI = (0, 40, 160, 80) while True: img = sensor.snapshot() img.binary([(0, 60)]) # 黑线白底场景，黑线二值化为白色 blobs = img.find_blobs([(255, 255)], roi=ROI, pixels_threshold=100) weighted_sum = 0 total_weight = 0 if blobs: for b in blobs: # 把blob的中心列映射到9个权重区间 col = b.cx() * 9 // img.width() if col >= 9: col = 8 weighted_sum += weights[col] * b.pixels() total_weight += b.pixels() if total_weight > 0: err = weighted_sum // total_weight # 归一化后的视觉偏差 else: err = 0 else: err = 99 # 特殊标志，表示断线或未找到线 # 串口发送：帧头0xA5 + 数值 + 帧尾0x5A data = bytes([0xA5, err & 0xFF, 0x5A]) uart.write(data) time.sleep_ms(20)

这段代码的核心就是把视觉信息压缩成一个字节的偏差值和断线标志，丢给STM32去处理。这样STM32端的控制逻辑可以保持简单，不需要跑图像算法，实时性反而更高。

5.3 OpenMV与STM32的UART通信细节

OpenMV和STM32之间最常见的通信方式是UART，接线就是TX接RX、RX接TX、GND共地。初始化时波特率建议都用115200，够快也不容易丢数据。STM32端用中断接收 + 环形缓冲区来缓存数据，然后主循环里解析，避免一次接收不定长数据时卡死。

通信协议我建议做帧头帧尾校验。我自定义的格式是0xA5开头、0x5A结尾，中间一个字节是偏差值。这样STM32收到数据后先找帧头，再等帧尾，两个都匹配才更新当前视觉偏差，否则丢弃这一帧等待下一个。这个简单协议在实际测试中基本不会出现粘包问题。

如果你后续想传更丰富的信息给STM32，可以在中间塞2~3个字节，比如“线位置/置信度/断线标志”。置信度这个字段很有用，可以让STM32端动态决定视觉信号的权重：置信度高时多听OpenMV的，置信度低时主听灰度传感器的。

6. 控制策略：STM32端如何融合两路信号做差速转向

6.1 多路数据的权重融合计算方法

到了STM32端，事情就变成了决策。灰度传感器给出的偏差量gray_err，OpenMV给出的偏差量vision_err，两者怎么合成一个最终的误差量？我的做法是加权求和，但权重不是固定的，而是根据当前状态动态调整。

计算公式是这样的：final_err = alpha * vision_err + beta * gray_err，其中alpha+beta=1。正常直线段上，灰度信号稳定，beta取0.7，alpha取0.3，让灰度主导；灰度信号全丢或者检测到十字全黑时，beta降为0.2，alpha升到0.8，让OpenMV主导；如果OpenMV传回断线标志，vision_err不参与，纯用灰度记忆值维持方向。

这里面最实用的一个技巧是对vision_err和gray_err做量纲统一。灰度偏差的范围一般是-3到+3，OpenMV传回来的是-4到+4，如果不归一化直接加权，两者数值范围不匹配，转向控制会被数值大的一方带偏。我在代码里把两边都映射到-100到+100范围再融合，这样权重alpha和beta才有实际意义。

6.2 PD控制器参数整定与差速输出映射

有了融合后的final_err，下一步就是用控制器把它变成左右轮的速度差。我选了PD控制而不是完整PID，因为小车在平地上跑，积分项容易造成过冲和振荡，去掉I反而更稳。PD输出就是steering = Kp * final_err + Kd * (final_err - last_err)，Kp控制转向力度，Kd抑制振荡。

参数整定没有捷径，我是这样一步步来的：先把Kp设成一个小值如2.0，Kd设0，让小车在直线段跑，观察是否抖动；然后慢慢加大Kp直到小车在弯道能稳定拐弯；出现轻微来回摆头时再加Kd，Kd从0.1开始微调。我最终的参数大概是Kp=2.5，Kd=0.6，不同车重和轮距会有差异，但方向就是这样调的。

左右轮PWM的计算就是最常见的那套差速逻辑：left_pwm = base_speed + steering，right_pwm = base_speed - steering。base_speed就是直行的基础PWM值，steering的正负决定转左还是转右。我用的PWM频率是10kHz，原因是N20电机在这个频率下噪音小、线性度也好，TB6612对这种频率支持得很稳。

有一点需要注意：PWM输出前一定要做限幅。比如base_speed=180，Kp最大输出30，那left_pwm可能到210，超出PWM最大值255还好说，但如果基础速度设太高，两边全满就失去差速效果了。我一般把PWM限制在100~255之间，低于100意味着电机接近堵转，方向修正反而失效。

7. 联调中的典型问题与排查技巧

7.1 电机干扰导致OpenMV通信乱码

这是联调第一天最容易遇到的问题。现象是电机一启动，STM32接收到的数据就开始出现0xA5 0x5A之外的乱码，有时候OpenMV发送正常但接收端就是解析不对。

排查思路是从干扰源下手：第一步把电机和单板的地线彻底分开；第二步在电机两端并联一个104瓷片电容加一个电解电容；第三步把所有信号线改成双绞线或者屏蔽线。实测下来最有效的是给电机驱动加上吸收电容，同时把OpenMV和STM32之间的串口线缩短到10cm以内，乱码概率降低非常多。

7.2 OpenMV帧率跟不上车速导致转向滞后

小车高速状态下，OpenMV每帧处理+传输要花30ms左右，这个延迟在1m/s的车速下意味着车身已经前移了3cm。如果控制周期和视觉帧率不匹配，小车会有明显的“看到弯道再转弯”的延迟感，弯道越大越明显。

我的解法是分级控制：灰度传感器每5ms采一次样，PD控制以5ms为周期跑；OpenMV的视觉偏差只在主循环里以50ms间隔更新一次。这样高速细调由灰度负责，OpenMV只提供慢速大方向修正。这个分频的思路和工业控制里的内外环很类似，实测下来稳定性明显优于统一50ms控制周期。

7.3 光照变化导致OpenMV误判线位置

上午调好的OpenMV阈值，下午拿到室外跑就失灵的案例我见过太多次。室内的白炽灯和窗外自然光混在一起时，地面反光强度会不断变化，固定阈值很不靠谱。

OpenMV端的解决方法是跟踪图像的平均亮度，动态调整二值化阈值。你可以每10帧计算一次画面亮度的平均值，如果整体变亮就适当提高二值化阈值，反之降低。这个自适应阈值逻辑不算复杂，但能明显提高视觉巡线的环境适应能力。另外尽量选择哑光地面测试，瓷砖反光严重的场地对任何一个视觉方案都是噩梦。

7.4 车速过快导致灰度传感器丢线

车速拉高之后，灰度传感器每隔几毫秒采样一次，但车身在采样间隔里已经位移了不少，可能出现四路都没对准黑线的情况。这不算传感器故障，是采样频率和车速的匹配问题。

我把ADC采样用DMA方式跑，配合定时器触发，把灰度采样频率提到1kHz，同时把去抖逻辑改成“连续两次一致才更新”，既保证了采样够密，又不会因为去抖太严丢失状态。实测车速在1.2m/s以内都能稳定跟踪。

8. 最后的经验总结

这套灰度+OpenMV权重判断的循迹方案，本质上是在用低成本硬件模拟高阶视觉循迹的大部分能力。灰度传感器负责快和稳，OpenMV负责远见和纠偏，权重判断负责在两者之间做仲裁，三个角色各司其职，缺一不可。整套系统的核心代码量并不多，但每一部分都有明确的物理意义，调试起来也能做到有的放矢。

回头看整个项目，我最想提醒后来者的一点是：不要一上来就追求豪华硬件和复杂算法，先把手头这套传感器组合的潜力榨干。我见过太多人花了大力气调OpenMV的神经网络模型，结果连基础的阈值和帧率问题都没解决。先把灰度阈值标定做扎实，把PD参数调到临界值附近，再把OpenMV的权重判断加进来做修正，这个顺序比反过来稳妥得多。

这套方案后续还有很多可以扩展的方向：比如把灰度路数从四路加到八路，提升近场分辨率；给OpenMV加一个颜色识别模块，实现区分红绿灯路口；甚至可以把控制算法升级成模糊PID，让小车在更极限的速度下依然稳定。但不管怎么扩展，灰度为主、视觉为辅、权重融合这个核心思路，在中小型嵌入式平台上都是性价比最高的选择。

本文还有配套的精品资源，点击获取