简介：STM32循迹小车完整工程包，面向电子设计竞赛、工程训练赛及单片机初学者，覆盖灰度传感器循迹与OpenMV视觉权重判断两条技术路线，用于解决小车自动识别路线并选择正确路径的控制问题。压缩包共106个文件、大小1.72MB，其中包含60个.h与23个.c源码文件，对应STM32 HAL库驱动、定时器PWM及电机控制逻辑；3个.py脚本用于OpenMV图像处理与权重判断；另有.ioc/uvprojx工程配置、hex固件、PDF/MD说明文档及烧录脚本，可帮助读者快速打开工程并对照学习。目前已有13562人学习/下载，资料在同类资源中热度较高。整套代码包含车体驱动、传感器采集、视觉识别和转向决策模块，并附有原理说明与调试工具，适合作为竞赛备赛或课程设计的完整参考方案。 做智能车竞赛或者课程设计的朋友，应该都经历过这样一个阶段：小车在地图上跑着跑着就冲出赛道，或者到了十字路口直接懵掉，不知道该往哪走。今天分享的这套“STM32循迹小车（灰度+OpenMV权重判断）”方案，就是用来解决这类问题的。它不是我拍脑袋想出来的组合，而是我在反复试过纯灰度传感器、纯OpenMV巡线之后，最终定下来的一套双传感器融合方案——用灰度阵列负责“稳”，用OpenMV负责“准”，两者通过权重判断融合，跑出来的效果比单一方案稳定得多。
这套方案的适用面很广：做智能车竞赛、电子设计竞赛的团队可以直接参考，课程设计选了这个题目的同学也能拿来当完整案例，甚至是想入门STM32+视觉融合的开发者，都能从里面拆到不少能用的东西。我会把方案怎么定的、灰度权重怎么算、OpenMV怎么配合、PID参数怎么调，以及我实际调试中踩过的那些坑，全部整理在这篇文章里。
1. 项目整体设计与方案选型
1.1 为什么是“灰度+OpenMV”而不是单方案
先说灰度传感器。它本质是一排红外对管，靠地面反射光的强弱来区分黑线和白底。优点是响应快、成本低、逻辑简单，适合高速、高频的底层循迹。缺点是视野太窄，只能看到车底附近的一小条带子，遇到十字路口、起跑线、断路这类“全局特征”时，信息量完全不够。
再说OpenMV。这个小摄像头能跑视觉算法，可以看到车前一大片区域的赛道结构。但它的帧率有限，一般跑30fps左右，如果完全依赖它来做循迹控制，高速下延迟会非常大，而且在光线变化剧烈的时候（比如赛道上有反光、阴影），单一视觉方案的鲁棒性也扛不住。
所以最终方案定为：底层循迹完全交给灰度传感器，OpenMV只负责识别“关键节点”——比如十字路口、起跑线、停止线、直角弯等，然后通过串口告诉STM32“前方是什么路况”，STM32再根据这个信息切换控制策略。两层分工明确，各干各擅长的事，而不是让两个传感器同时抢着控制转向，这就是这套方案的核心逻辑。
1.2 系统架构与决策流程
整个系统的信息流是这样的：
- 灰度传感器以固定频率（我实际用2ms一次）扫描地面，计算当前偏差值，直接送入转向PID，保证小车紧紧咬住黑线。
- OpenMV以30fps采集图像，判断当前赛道特征（直道/十字/起跑线），通过串口发给STM32，STM32解析后维护一个“赛道状态机”。
- 当灰度判断到小车处于“异常状态”（比如全白、全黑、偏差突然跳变）时，STM32不盲信灰度结果，而是结合OpenMV给出的前方路况，做加权决策。
说白了就是：灰度管“脚底下”，OpenMV管“前方视野”。两者不是竞争关系，而是上下级关系，灰度是执行者，OpenMV是情报员。
从竞赛地图设计的角度来说，这套架构对赛道元素的兼容性也比较好。常见的竞赛地图无非是直线、弯道、十字、起跑线、断路这几种，纯灰度方案在十字路口容易丢线，纯视觉方案在高速直道上反应又不够快，融合之后各自的问题都被对方补上了。
2. 权重判断的核心：灰度阵列算法推导与实现
2.1 从“三态判断”到“加权偏差”：数据量化的关键
很多刚接触循迹小车的同学，第一次写的代码基本都是“if-else三态判断”，比如左边传感器见黑就往左打，右边见黑就往右打。这种写法在低速慢跑时能用，但速度一上来就露馅，因为转向量只有“有/无”两种状态，没法做到平滑过渡，小车走起来就是一顿一顿的蛇形。
正确做法是把多个传感器的状态值加权求和，得到一个连续的偏差量。以8路灰度为例，每个传感器有一个编号，从最左边到最右边分别是-4、-3、-2、-1、1、2、3、4（中间留空避开0，防止死区），每路检测到黑线时输出1，否则输出0。偏差计算公式为：
error = (value[-4] * (-4) + value[-3] * (-3) + ... + value[4] * 4) / count其中count是当前亮起的传感器数量。这样算出来的error是一个连续值，范围在-4到4之间。如果小车刚好在线的正中央，error约为0；如果稍微偏左，左边的传感器亮起，error变成负值，控制器就会自动向右修正。
这里有个细节值得注意：除以count是为了做归一化处理。如果不除，车在过粗线的时候，多个传感器同时亮起，偏差会突然变得很大，转向就会猛地抽一下。归一化之后，偏差只反映“线在车的哪个方向”，而不是“线占了多少个传感器”，控制起来就稳很多。
2.2 偏差计算代码与PID闭环接入
实际代码里，我建议把加权计算封装成一个独立函数，方便调试和复用。下面这段是在STM32上用标准库写的核心逻辑：
int16_t Gray_GetError(void) { uint8_t i; int16_t sum = 0, count = 0; int16_t weight[8] = {-4, -3, -2, -1, 1, 2, 3, 4}; for (i = 0; i < 8; i++) { if (gray_state[i] == BLACK) { sum += weight[i]; count++; } } if (count == 0) { // 全白：丢线状态，返回一个特殊标志 return GRAY_LOST_LINE; } return sum * 100 / count; // 放大100倍提高精度 }把这个error送进PD控制器：
int16_t steering_output = Kp * error + Kd * (error - last_error); last_error = error;这样就得到了一个连续的转向控制量，再映射到舵机或者差速轮的PWM占空比上，小车的走线会明显顺滑很多。我实际调试下来，Kp在0.8到1.5之间、Kd在0.05到0.2之间是比较常见的区间，具体值跟你的车体结构、传感器高度、速度都有关系，没有通吃的参数。
2.3 OpenMV的权重融合：什么时候信谁
OpenMV识别出的路况信息，本质上也是一个“置信度”问题。比如它判断前方是十字路口，但这个判断可能因为图像模糊、反光等因素出错。所以我在设计融合逻辑时，给OpenMV的判断也加了一个权重因子。
// STM32端接收OpenMV数据格式示例 // 帧头 + 路况类型 + 置信度 + 帧尾 // 0xAA 0x01 0x64 0xBB 表示“十字路口，置信度100%”置信度由OpenMV端根据识别结果的稳定性给出，比如连续5帧都识别为同一路况，置信度就高；如果识别结果来回跳变，置信度就低。STM32端只有当置信度超过70%时，才信任OpenMV的识别结果，否则视为无效数据。
这套机制在实际跑起来非常有价值。灰度传感器在高速通过十字路口的时候，大概率会瞬间全白丢线，如果此时OpenMV已经提前报出“前方是十字”，STM32就会进入“直行策略”，而不是按照灰度的全白状态去原地打转。反过来，如果OpenMV偶尔误判了，置信度不够高，灰度也能兜底，不会直接被带偏。
3. 实操过程：硬件接线、工程配置与联调
3.1 灰度传感器选型与接线避坑
灰度传感器市面上常见的型号有TCRT5000和ITR20001T，8路成品模块也有很多，比如“寻迹宝”这类。选型时要注意两点：
第一是传感器间距。间距太小，过弯时容易同时压线导致偏差不准；间距太大，又容易在细线上丢线。我试过5mm、8mm、10mm三种间距，最终在轮距16cm的小车上选了8mm间距，兼容性和精度比较均衡。
第二是供电稳定性。8个红外对管同时工作，瞬间电流能到200mA以上，如果直接吃STM32芯片的3.3V输出，电压会跌落，导致传感器读数漂移。稳妥的做法是用单独的5V供电给传感器模块供电，数字输出引脚再通过电平匹配后进STM32的GPIO。
接线方面，如果用的是模拟量输出的灰度模块，需要占用8路ADC引脚；如果是数字量输出，只需要8路普通GPIO，读电平就行。我用的是数字量输出的版本，代码处理更直接，抗干扰也更好。
3.2 OpenMV与STM32的通信：串口和SPI怎么选
OpenMV和STM32之间的通信，我试过两种方式：UART和SPI。
UART是最简单的方式，代码量少，调试方便，接线只要TX/RX交叉相连、共地即可。缺点是速度上限一般，115200bps下传一帧8字节数据大概需要0.7ms，对于30fps的视觉识别完全够用。我的建议是，除非你对帧率有极端要求，否则直接用UART，能把调试时间压缩一大半。
SPI的速度可以做到几Mbps，传输大块图像数据没问题，但代码复杂度高，还得处理片选、时钟极性等细节，在竞赛这种时间节点紧张的场景下，性价比不高。很多朋友在搜索时会看到“OpenMV怎么SPI通信”这类问题，说实话，如果只是传几个字节的识别结果，SPI的优势根本体现不出来，UART才是更务实的方案。
STM32端接收OpenMV数据的代码，我建议用串口空闲中断加DMA的方式，既能保证数据及时性，又不占用主循环资源：
// 伪代码示例，实际工程可根据平台调整 void UART_IDLE_Callback(void) { if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); HAL_UART_DMAStop(&huart1); process_openmv_frame(rx_buffer, rx_len); HAL_UART_Receive_DMA(&huart1, rx_buffer, BUFFER_SIZE); } }3.3 核心代码模块与工程搭建要点
完整的工程分这么几个模块：灰度采集模块、OpenMV通信模块、赛道状态机、转向/速度PID控制。开发环境我用的是Keil 5，配合STM32标准库，这套组合最成熟，遇到问题也最容易搜到答案。
如果是从零开始搭工程，我的建议是直接在STM32CubeMX里初始化时钟、GPIO、定时器、串口和DMA，然后代码逻辑用标准库写。CubeMX能省掉一大堆寄存器配置的时间，但生成的代码结构偏臃肿，所以我的习惯是：用CubeMX生成初始化代码，业务逻辑自己新建文件夹管理。比如：
/Project /Core // CubeMX生成 /Hardware // 灰度、OpenMV、电机驱动驱动层 /Algorithm // PID、权重计算、状态机 /App // 主逻辑这样分层清晰，后续调试哪个模块就直接进对应的文件夹，不需要在一堆代码里翻找。
关于定时器的使用，灰度扫描和PID运算需要固定的时间基准。我用TIM3做了2ms的定时中断，在中断里做灰度采集、偏差计算、PID输出。注意中断函数里的代码尽量精简，不要做耗时操作，比如串口打印这种，一旦放进中断里，很容易把整个控制周期拖慢。
4. 常见问题与竞赛避坑实录
4.1 灰度传感器状态判断混乱：单行变双行的干扰
这是我觉得最值得说的问题。竞赛地图上偶尔会有双线并行的区域，或者赛道边缘有装饰性图案，灰度传感器很容易被旁边的黑线干扰，导致偏差计算乱跳。
我踩过这个坑之后，解决方案是在灰度模块里加入“主峰识别”逻辑——不是简单地对所有亮灯传感器做加权，而是先判断哪一组传感器连续亮起的数量最多，只对这一组做加权。具体实现也不复杂，先遍历8路状态，统计连续亮起的“连通域”，找到长度最大的那个区间，再用这个区间的传感器做权重求和。
这样处理后，即使边上有一条装饰黑线，主峰识别也能锁定真正的赛道线，不会左右摇摆。竞赛用的地图设计越复杂，这个逻辑就越重要。
4.2 速度一快就飞线：PWM死区与转向死区
小车低速跑得好好的，一加速就冲出赛道，这是PID参数没匹配好，或者没做死区处理。转向控制里有个“死区”概念：当偏差小于某阈值时，舵机/差速轮不动作，否则微小的波动会导致转向机构不断抖动，白白消耗响应速度。
实际调参过程中，我习惯先用一个固定的低速测试灰度权重逻辑，保证慢速过弯不丢线；然后逐步提高目标速度，每提高一档就微调一次Kp和Kd。速度越快，Kd的作用越明显，因为需要靠微分项抑制过冲，但Kd也不能调太大，否则转向会发涩，过弯反而变迟钝。
另外，用差速轮的小车要特别注意PWM的下限值。由于电机存在死区，PWM太小根本转不起来，这时候小车在直道上会走走停停。我是在代码里加了PWM补偿：
void Motor_SetSpeed(int16_t left, int16_t right) { left_pwm = (left > 0) ? (left + MOTOR_DEADZONE) : (left - MOTOR_DEADZONE); right_pwm = (right > 0) ? (right + MOTOR_DEADZONE) : (right - MOTOR_DEADZONE); // 限幅处理 }实测下来这一处小改动，对低速段的稳定性改善非常明显。
4.3 工程层面的几个坑：延时卡死、烧录失败、连接线松动
在调试过程中，工程层面也有一些容易浪费时间的坑，我简单记录一下：
“stm32延时函数delay卡死”。这个问题我遇到过，原因是用了SysTick做延时，但同时又初始化了其他中断，SysTick优先级没配好，导致延时被中断打断后一直死等。解决办法是把SysTick中断优先级调到最高，或者改用DWT计数器做延时，完全不依赖中断，更稳定。
关于烧录失败的问题。很多新手第一次接触失败会懵，其实多半是BOOT引脚配置问题，或者是ST-Link驱动没装好。STM32的启动模式有从Flash启动、从系统存储器启动等几种，BOOT0和BOOT1引脚的组合决定了启动方式。如果你用ST-Link烧录提示连接不上，先检查BOOT0是不是接了3.3V，正常调试时应该拉低。我用的是stm32 st-link utility配合ST-Link烧录，比Keil自带的下载器界面更直观，也能在连不上芯片的时候多给一些底层提示。
灰度模块的连接线松动。这个听起来低级，但实际比赛中真的会因为一个杜邦线虚接，导致小车跑到一半突然疯转。做完整的排查花费两三个小时都没找到原因，最后发现是插头松了。建议所有传感器模块的排线都打胶固定，或者直接用焊锡焊接，不要用杜邦线。
4.4 OpenMV识别不稳定：光照变化与帧率取舍
OpenMV在室内固定灯光下识别很稳定，但到了竞赛场地，光线条件一变，识别率就可能下降。我的处理方式是在OpenMV端做灰度自适应——先统计图像的平均亮度，然后动态调整二值化阈值，避免“白天能识别、晚上就瞎了”的问题。
另外，如果你发现OpenMV识别延迟比较大，可以在代码里降低分辨率，比如从640x480降到320x240，处理速度能快不少。辨率降低对巡线特征识别影响其实不大，因为赛道特征都是大色块，低分辨率完全够用。
5. 写在最后的调试心得
这套“灰度+OpenMV权重判断”方案，我从理论到落地到竞赛调试，花了大约两周时间。中间踩过不少坑，但走通之后，整体控制的稳定性和速度上限都让我满意。尤其是OpenMV的置信度判断和灰度主峰识别这两个点，一个解决了“信任谁”的问题，一个解决了“单线多线干扰”的问题，是最值得留作经验复用的部分。
最后想补一句：做循迹小车，最重要的不是一开始就追求复杂的算法，而是先把灰度权重闭环跑通，让小车在低速下能稳定走线，再逐步加上OpenMV路况识别、PID参数优化、速度提升。每一步都有明确的验证标准，出了问题也容易定位。可以试试自己从头搭一块，跑完一圈完整赛道之后，你会回来感谢这套方案的。
本文还有配套的精品资源，点击获取
