企业官网建设流程全解析

视觉巡线小车这个项目，我前后折腾了两个多月才算是真正跑稳了。网上的资料看着都很全，OpenMV有寻线例程，STM32有电机驱动例程，可真把两套东西拼到一起的时候，各种问题才冒出来——通信对不上、图像突然丢线、弯道转不过去、电池电压一降小车就像喝醉了一样。这篇文章是把整个项目的技术路线从头到尾捋一遍，重点放在系统架构、硬件接线、视觉处理、通信协议、差速控制和联调排错上，把我调通的方案和踩过的坑都写清楚。

适合正在做智能车竞赛、课程设计，或者想用低成本方案学习视觉闭环控制的朋友。不说废话，直接进正题。

1. 系统架构：谁当眼、谁当脑、怎么分工

1.1 OpenMV和STM32为什么各干各的

做视觉巡线，第一件事不是写代码，而是把架构想清楚。市面上有两类常见方案：一类是OpenMV单独干完所有事——图像识别、PID计算、PWM输出全都塞给OpenMV，靠它的IO口直接驱动电机；另一类是OpenMV只做图像识别，把结果通过串口发给STM32，由STM32完成运动控制和PWM输出。

我最终选了第二种。OpenMV的理想虽然不错，但它本身也是一块基于STM32H7的小板子，把CPU大量花在图像处理上没问题，可一旦同时做高频PID控制和PWM刷新，实时性很容易被打折扣。巡线车对控制频率的要求并不低，我的控制周期设计在20ms左右，也就是50Hz，如果图像处理偶尔卡一下，整个控制链路就跟着抖。

更重要的是分工边界清晰。OpenMV干它最擅长的：图像采集、预处理、特征提取、输出一个结构化的偏差结果。STM32干它最擅长的：接收指令、做PID计算、输出PWM、处理电机状态。两边各管一摊，调试的时候也能分开定位问题——车不动了，先看OpenMV有没有发，再看STM32有没有收，不用全堆在一起查。

1.2 数据流与任务边界划分

整个系统的数据流是这样的：

OpenMV摄像头采集画面，在ROI区域内做色块识别，对目标色块做线性回归，算出线条相对画面中心的偏角（theta值），然后把偏角打包成一帧数据，通过UART串口发给STM32。STM32在串口中断里接收并解析出偏角数据，把它作为PID控制器的输入偏差，计算出一个转向修正量，叠加到基础速度上，得到左右两个电机的目标PWM占空比，通过定时器输出到电机驱动芯片，驱动直流减速电机转动。

这个链路里有两个隐含的设计要点。

第一，OpenMV只往上抛“偏差”而不抛原始图像。很多人初学者喜欢把整张JPEG图通过串口发给STM32让单片机去处理，这个思路在窄带宽下完全不现实。QVGA分辨率一张JPEG图轻轻松松几十KB，115200波特率下传一张要好几秒钟，小车早就冲出赛道了。正确做法是在前端把图像压缩成一个浮点数，比如偏角-45到45度，串口每帧只需要传输几个字节，效率完全不在一个量级。

第二，STM32不需要理解“图像”这个概念。它眼里只有一串数字：当前偏差是多少、目标偏差是0（正对线条中间）。所有和图像有关的逻辑全放在OpenMV端，所有和运动有关的逻辑全放在STM32端。这种解耦让两边可以独立升级，比如以后想从巡线改成巡十字路口，只需要改OpenMV端的识别策略，STM32端完全不用动。

2. 硬件选型与接线，少走弯路的几个决定

2.1 电机驱动方案：L298N、TB6612怎么选

电机驱动芯片的选择直接影响整个系统的稳定性和体积。做视觉巡线小车，市面上最常见的三个选择是L298N模块、TB6612FNG模块，以及DRV8833等小电流驱动。

先说我用过的L298N。它的优势是便宜、功率裕量大、接法简单，网上教程铺天盖地。但它的劣势在实际用起来相当明显：内部是双H桥电路搭配PN结三极管，导通压降很大，实测在1.5V到2V左右。这意味着7.4V电池经过L298N送到电机两端，实际有效电压可能只有5.5V到6V。而且压降随着电流增加还会变大，电机转速和你预期的差一大截。更头疼的是L298N模块上的线性稳压芯片78M05，输入7.4V时它自身发热就很厉害，我用手摸过，烫得不能久放。

后来我换成TB6612FNG，这个芯片使用MOSFET做H桥，导通压降只有0.5V左右，同样电池电压下电机能获得更高有效电压。它本身体积只有L298N模块的几分之一，还支持PWM频率直接输入。TB6612的逻辑电源和电机电源是分开的，逻辑部分用3.3V供电时，输入引脚可以直接兼容STM32的3.3V电平，不用额外加电平转换。

综合来看，在电流需求不大的场景下（比如N20减速电机，堵转电流在2A以内），TB6612是明显更优的选择。如果用的是大功率电机或者要求特别皮实，那再考虑L298N或者分立MOSFET驱动方案。

2.2 串口连接与电平匹配：最容易翻车的地方

OpenMV和STM32之间的串口连接，看似就是两根线，但翻车率非常高。

OpenMV的UART引脚是3.3V逻辑电平，STM32F103的IO口也是3.3V逻辑电平，理论上可以直接相连。但有一个细节很多人忽略——必须共地。两块板子如果不共地，TX和RX引脚的参考电位就不同，出来的波形完全乱套。我见过好几个人说“串口收到的全是乱码”，最后发现是只接了两根信号线、没接GND。这是新手最容易犯的错误，也是最容易解决但最难发现的。

接线方案上，我用的是OpenMV的UART3（P4为TX，P5为RX）对STM32的USART1（PA9为TX，PA10为RX），交叉连接：OpenMV的TX接STM32的RX，OpenMV的RX接STM32的TX。注意一定要交叉，接反了就成了两边都发不收，毫无反应。

还有一个容易踩的坑：OpenMV的P0到P5这些引脚有些是复用的，如果之前做过其他实验，引脚可能被配置成其他外设功能。我建议在代码里明确初始化UART引脚，别依赖默认状态。

2.3 电源分配：共地与压降问题

供电方案我踩过不少坑，最终定型为：

• 电池：7.4V 2S锂聚合物电池，容量1800mAh
• 电机电源：直接取自电池正负极，经TB6612的VM引脚供电
• 逻辑电源：电池电压经过MP1584降压模块输出5V，一路给OpenMV供电，一路给STM32的5V引脚（板载稳压到3.3V）
• 共地：所有电源地必须连在一起

这里最关键的一点是：电机不要和单片机共用同一路电源。直流电机的启动电流和堵转电流波动非常大，如果从同一个降压模块取电，电机一转，电压就往下掉，STM32和OpenMV瞬间复位，这是很多“小车一启动就重启”问题的根源。

还有个细节，MP1584这类降压模块输出纹波大小和负载有关，给OpenMV供电时，OpenMV的CMOS传感器对电源纹波比较敏感，我实测过纹波偏大会导致画面出现横条纹。解决办法是在OpenMV电源输入端并联一个100uF电解电容和0.1uF陶瓷电容，效果立竿见影。

3. OpenMV视觉识别：从像素到转向指令

3.1 图像预处理：为什么盯着灰度阈值而不是实际颜色

打开OpenMV IDE，很多人第一个动作就是打开阈值编辑器，对着一块黑色电工胶布调LAB阈值，然后把阈值写进代码就完事了。这样做确实能在当前光照下跑起来，但换个环境、换个时间段，阈值就失效了。

我的做法是分两步。第一步，固定传感器参数：关闭自动增益、关闭自动白平衡、固定曝光时间。原因很简单，自动曝光会根据画面亮度动态调整曝光时间，一旦调整，同一块黑胶布在不同画面帧里可能呈现完全不同的LAB值。在室内灯光比较稳定的条件下，完全可以用固定参数。我在教室日光灯下的曝光时间设在20000us左右，增益固定，白平衡固定，画面稳定得很。

第二步，在固定参数下重新标定阈值。具体操作是把OpenMV对着赛道，用IDE自带的阈值编辑器（Tools -> Machine Vision -> Threshold Editor）框选线条区域，观察LAB三通道的取值范围。比如我调出来的一条黑色胶布阈值是(0, 30, -20, 20, -20, 20)，意思是L通道0到30（很暗），绿色分量-20到20，蓝色分量-20到20。实际保存时我会留一点余量，把范围稍微放宽，避免光线轻微波动就丢线。

3.2 get_regression线性回归：为什么比找色块中心更稳

OpenMV巡线有两大流派：一个是find_blobs找出所有色块，取最大色块的中心坐标作为偏差；另一个是get_regression直接在线条上做线性回归，输出线条的角度和偏移量。

我一开始用的是find_blobs思路：找到线条的色块中心x坐标，和画面中心比较得出横向偏差，然后传给PID做转向。在直道上这个方案没问题，但到了弯道就很吃力。因为弯道上色块是弯曲的，色块中心并不等于弯道出口方向。再加上反光、断线、光照不均，色块中心会乱跳，小车表现就是左晃右晃。

换成get_regression之后稳定性提升了非常多。这个函数对满足阈值条件的像素做鲁棒线性回归，返回一个包含角度theta和偏移量rho的Line对象。theta是线条相对垂直方向的角度，范围0到180度；rho是原点（画面左上角）到回归直线的垂直距离。

实际控制中，我最关心的是线条在当前画面中的角度。小车在直道上时theta接近90度（线条基本垂直），在右弯时theta会偏大或偏小，根据摄像头安装方向而定。把theta经过归一化映射到-90到+90之后，直接作为PID的输入偏差使用。相比色块中心坐标，角度信息对未来趋势的预判性更强，弯道表现好很多。

3.3 ROI裁剪与姿态标定

ROI（感兴趣区域）的设置不是随便框一块就行。我的经验是把ROI放在画面下半部分，大约占整个画面高度的60%，宽度取全宽。为什么这样做？

首先，画面下方的线条是离车最近的部分，也是控制最需要关注的前瞻区域；画面上方远处的线条容易因为透视关系变得很细很模糊，反而干扰回归结果。其次，ROI越小，需要处理的像素越少，帧率越高，控制延迟越低。OpenMV在QVGA分辨率下，全画面线性回归大概能跑30到40帧，裁掉上半部分后能稳定在50帧以上。

姿态标定是另一个容易忽略的点。把小车放在直线上，让车身完全回正，然后看OpenMV输出的theta值是多少。绝大多数情况下不是整数90，可能是92或者88。这个偏差需要在代码里做零点修正。我用一个offset变量保存标定值，每次计算偏差时减去它：error = theta - 90 - offset。如果不做这一步，小车在直道上就会一直有一个固定的侧向力，表现为走不直。

另外还要注意摄像头的安装方向。我习惯让OpenMV的Y轴正方向指向小车前方，这样线条在画面里呈现的角度和小车的转向方向是直观一致的。如果摄像头装反了，theta的符号和实际转向会相反，PID一输出就是反向打方向，小车会直接冲出去。

4. 通信协议：一帧数据怎么做到既简单又可靠

4.1 帧格式设计：帧头、载荷、校验

OpenMV到STM32的数据量很小，本质上每次只需要传一个角度值，但通信协议的健壮性不能省。如果直接uart.write(char(theta))，一个字节发过去，看起来简单，问题在于STM32收数据时根本不知道这个字节什么时候到、是不是完整的一帧、中间有没有丢字节。

我的做法是定义了一个非常简洁的帧格式：

角度值我用int16表示，单位是0.1度。比如45.3度就编码为453，这样保留了一位小数的精度，又不使用浮点数传输。整帧一共8个字节，在115200波特率下传输时间不到0.7ms，对20ms控制周期来说完全可忽略。

帧头的选择有讲究。我不用单字节0xAA做帧头，而是用0xAA 0x55双字节。原因是数据载荷里的字节可能恰好是0xAA或0x55，双帧头加上校验和，能把误同步的概率压到非常低。校验和算法也不用CRC，累加和就够用了——通信距离短、环境干扰小，单字节累加和的检错能力在这个场景下足够，而且STM32端实现起来只有一条循环。

4.2 STM32端状态机解析

STM32端的接收逻辑，我建议不要用简单的if(USART_GetITStatus)里一个字节一个字节地缓存再统一处理，而是用状态机解析。状态机的好处是天然处理粘包和半包问题。

我定义了一个状态枚举：

typedef enum { FRAME_STATE_WAIT_HEAD1, // 等待第一个帧头 0xAA FRAME_STATE_WAIT_HEAD2, // 等待第二个帧头 0x55 FRAME_STATE_WAIT_LEN, // 等待数据长度 FRAME_STATE_WAIT_DATA, // 等待数据载荷 FRAME_STATE_WAIT_CHECK, // 等待校验和 FRAME_STATE_WAIT_END // 等待帧尾 } FrameState;

串口中断每收到一个字节，就驱动状态机向前走。在WAIT_DATA状态里，按照长度字段把载荷字节存进数组。收完载荷后进入校验状态，计算累加和并与收到的校验字节比较，一致则再检查帧尾，全部通过就把角度值提取出来，存入一个全局变量，同时置一个“新数据到达”标志位。主循环检测到这个标志位后，直接读取角度值并清零标志。

这套逻辑的核心价值在于：即使某一帧丢了一个字节或者错了一个字节，状态机不会一直卡死。错误字节会导致校验失败，状态机自动回到等待帧头的初始状态，从下一帧重新开始同步。我刚开始用傻瓜式接收时，一帧错了后面全乱，必须复位才能恢复，换成状态机后鲁棒性好了很多。

4.3 串口调试中遇到的数据错位与粘包

调试通信时最容易遇到的问题有三个：乱码、错位、粘包。

乱码大概率是波特率不匹配或者电平/共地问题，这个排查起来相对直接。错位则表现为帧头能对上但数据明显不对，比如角度值突然跳到几千，原因可能是OpenMV发送端在初始化时先发了一堆未定义数据，或者两帧之间间隔太短导致STM32一次中断处理时缓存里挤了多帧数据。粘包其实是串口通信的正常现象，串口把短时间内到达的字节全放在缓冲里，应用层拿到的数据可能是“半帧+整帧+半帧”的混合。

处理粘包的思路不是让发送端慢一点（那会牺牲帧率），而是在解析端做状态机容错。上面说的状态机天然能应付：每帧之间即使没有间隔也不怕，因为帧尾和帧头是明确区分的，状态走完一帧紧接着从WAIT_HEAD1开始处理下一帧。另一个实用技巧是调试阶段在OpenMV端每发送完一帧后，用IDE的串口终端打印一个带帧序号的调试信息，STM32端也把解析结果通过另一个串口发到电脑，两边同时看，非常有利于快速定位是哪一端出了问题。

5. 转向控制：差速模型与PID整定实操

5.1 两轮差速如何换算成PWM

小车底盘用的是两轮差速结构——左右两个独立驱动的轮子，加上前后各一个万向轮或牛眼轮。转向靠左右轮速度差实现。

控制量换算的核心公式非常直观：

left_pwm = BASE_SPEED + steering_output; right_pwm = BASE_SPEED - steering_output;

其中BASE_SPEED是基础速度，对应小车直线行驶的PWM占空比，我一般设在50左右（PWM周期设1000，即50%占空比）。steering_output是PID控制器输出的转向修正量，范围限制在-40到+40之间，避免修正量过大导致某一侧反转反转或者另一侧占空比超过100%。

这个公式隐含了一个假设：左右轮在相同占空比下转速相同。实际上由于电机个体差异、轮胎磨损、地面摩擦不同，左右轮不可能完全一致。我在代码里加了一个静态标定系数，实测在直道上让小车跑起来，微调某个轮的增益，直到它走直线。这个标定值在不同电量下要重新检一次，后面讲掉电问题时再说。

PWM输出用STM32定时器的PWM模式实现。我用TIM2的CH1和CH2作为左右轮PWM输出，ARR设为999，也就是输出频率72kHz/1000=72kHz，对于直流减速电机来说这个频率远超人耳可闻范围，电机运行安静且没有啸叫。控制方向用TB6612的AIN1/AIN2和BIN1/BIN2两个引脚，一个设为高一个设为低就决定正转反转，两个都低就是刹车。

5.2 PID三参数分工和调参顺序

视觉巡线的PID控制，用角度偏差作为输入是很自然的：目标值是0（小车正对线条方向），实际值是当前偏角。这里我用的是增量式PID，输出是转向修正量。

先简单回顾三个参数的分工：

• Kp（比例）：偏差越大，修正越猛。只加Kp时，小车在直道上会来回摆动，因为修正量总有滞后，冲过头了又要反方向修回来。
• Ki（积分）：消除静差。在巡线场景中，如果光照变化导致线条识别系统偏差，或者底盘左右轮标定不准，比例控制会留下一个稳定偏差，积分项可以慢慢补上。
• Kd（微分）：抑制振荡。偏差变化越快，输出的反向阻尼越大。在弯道入弯时，角度突然变大，微分项能预判趋势，减少超调。

我调参的顺序是：先把Ki和Kd设成0，只加Kp，从小往大加。设定Kp=10跑一圈，小车在直道上来回晃，Kp加到40左右，直道基本稳住，但弯道入口会有明显抖动。然后加Kd，从Kd=20开始，逐步加大到80，弯道抖动明显改善，入弯时更顺滑。最后加很小的Ki，Ki=1到3就够了，用来补偿静态偏差。

实际调的时候有个观察技巧：让OpenMV通过串口把theta值实时发给电脑，用串口绘图软件（比如VOFA+或者SerialPlot）画出偏差曲线。直道行驶时看曲线的振荡频率和振幅，弯道行驶时看曲线的超调量。一味调大Kp会让曲线变成高频率低幅度的锯齿状，适当增加Kd可以让曲线更平滑，但如果Kd过大，整个系统会变得迟钝，弯道响应变慢。

5.3 弯道策略：偏角大时先减速再转向

这是整个项目里提高完赛率最有效的一个优化。

巡线车的死法大多数不是直道翻车，而是弯道——入弯速度太快，转向修正来不及跟上，车直接冲出赛道。我在PID调了差不多之后，加了一个简单的分层策略：

if (abs(error) > 45) { base_speed = 25; // 大角度急弯，降速 } else if (abs(error) > 20) { base_speed = 38; // 中等弯道 } else { base_speed = 50; // 直道或小偏差 }

这里的逻辑并不复杂：偏角越大说明弯道越急，越需要降低前进速度，提高转向修正量的相对权重。实测下来，加了这道速度分层后，急弯过弯成功率明显提升。要注意的是，切换速度时不能跳变，否则会产生顿挫感。我在代码里加了一阶低通滤波，对base_speed做了平滑过渡，每次调节步长不超过3。

还有一种进阶玩法是“前瞻距离”动态调整ROI：速度高时把ROI放远一点，提前看到弯道趋势；速度低时ROI拉近，减少干扰。这个我在后期调过，效果有，但对赛道环境依赖比较大，如果赛道颜色反光严重，远端ROI反而容易误检。如果你的赛道比较简单干净，可以试试这个方向。

6. 联调阶段的典型故障与完整排查链路

6.1 画面正常但小车不动，逐级定位法

这是最常见的问题，也是最值得认真捋一遍排查思路的问题。我的办法是从信号链路的源头到末端逐级检测。

第一级，确认OpenMV是否在发送。用OpenMV IDE的串口终端，在代码里加一条print(theta)打印语句，跑起来看IDE终端是否有数据滚动。如果终端有数据，说明OpenMV的识别和打印逻辑正常，问题可能在UART发送管道。注意检查uart = UART(3, 115200)的初始化是否在sensor.skip_frames()之后，一些复用引脚的配置冲突会在初始化时报错。

第二级，确认OpenMV物理上是否发出来了。用USB转TTL工具接在OpenMV的TX引脚上，在电脑串口助手里看有没有帧数据。如果这里没有数据，很可能是引脚定义错了。OpenMV的UART3对应引脚是P4（TX）和P5（RX），这个一定要查芯片手册核对，不同型号OpenMV的引脚映射可能有差异。

第三级，确认STM32是否收到了数据。在STM32串口中断里加一个计数器，每收到一字节计数加1，接上OpenMV后看计数是否增长。如果计数不动，检查TX到RX的线是否接好、是否交叉、共地是否正常、两块板子的3.3V参考是否一致。

第四级，确认数据是否解析成功。在状态机解析通过后置位一个LED，如果LED不亮，说明协议封装不一致——两边对帧头、帧尾、校验的定义必须完全一致，一个字节都不能差。这里最容易出问题的是OpenMV端写了一个整帧字符串发送，而STM32按逐字节状态机解析，两边对“数据长度”的理解不一致。

第五级，确认PWM是否输出。用示波器或万用表频率档测STM32定时器PWM引脚，如果无波形，检查定时器初始化、GPIO复用配置。如果有波形但在电机端无反应，测一下TB6612输入侧PWMA/PWMB有没有波形、方向脚的电平对不对、VM电源是否到位。

快速定位原则是：动作没发生，先从源头往下游推；数据不对，先用逻辑分析仪抓波形看帧格式。我那次调了很久才发现是OpenMV的TX接到了STM32的PA9上，而PA9正好是USART1的TX，等于两边都在发，信号完全冲突。

6.2 直道正常弯道抖，问题可能出在曝光

直道稳、弯道抖甚至丢线，这个现象排查到最后很多人会去调PID，但一次很偶然的机会让我意识到问题在图像侧。

当时我在室内日光灯下测试，跑直道时OpenMV的线性回归输出基本稳定在90度附近。但一进弯道，由于弯道处线条在画面中会形成更宽的反射区，或者日光灯的频闪效应导致两帧画面的亮度差异大，get_regression输出的theta在弯道边缘出现了跳变，比如从70度突然跳到92度，然后再跳回75度。PID拿到这个跳变的输入，输出自然疯狂抖动。

解决办法有两层。第一层是把曝光时间固定下来。50Hz交流电的日光灯频闪是100Hz，如果曝光时间不是灯光周期的整数倍，每帧画面亮度就会周期性波动。我把曝光时间设在10ms（20ms半周期的整数倍），亮度波动明显减小。第二层是在OpenMV端对输出做滤波，我用简单的递推平均，连续存5个theta值取平均，作为真正发送到STM32的结果。这个滤波会引入一点延迟，但换来的是控制输入平滑，PID的压力小很多。

另外补充一个排查弯道抖动的技巧：把OpenMV的img.draw_line(line.line(), color=(255,0,0))画线结果通过IDE的帧缓冲区显示出来，录一段像，逐帧看弯道处回归线和实际线条的贴合情况。你会很直观地看到是不是识别本身在跳，而不是控制端在抖。

6.3 电量下降后行为漂移的根治思路

锂电池从满电4.2V每节到放电截止3.7V左右，总压会从8.4V降到7.4V，幅度超过10%。对直流电机来说，这个压降会导致同样PWM占空比下转速明显下降。因此小车充满电时跑得好好的，跑了五六分钟后开始出现转向不足，过弯越来越费劲。

如果只靠PID本身，理论上能自适应一部分——因为PID是基于误差反馈的，误差大了输出就大。但问题是PWM已经接近限幅，当基础速度设得太高，转向修正量被推到了+40的极限，仍然不足以产生足够的差速，于是车就出赛道了。

我的根治方案有两个层面。第一，把基础速度设在一个宽电压范围内都留有余量的值。以7.4V满电时测试，如果最大合适占空比是60%，那么基础速度设到45%（而不是48%）作为满电状态的初始值，这样即使电压降到7.0V，系统还有调节空间。第二，在STM32端用ADC实时采集电池电压，做一个分段补偿：电压每下降0.2V，基础速度增加2到3个PWM位。这个方案实测很有效，整块电池的放电过程中小车表现都趋于一致。

还有一个细节很多人不注意：电量低时TB6612的VCC逻辑电压虽然是3.3V稳压出来的，但如果电池电压低于某个值，降压模块的输出也会跌，导致STM32供电不稳开始复位。我现在会在代码里加一个低电压警告：电池电压低于6.8V时，蜂鸣器响一声，提醒该换电池了。别等到完全没电再换，对锂电池寿命和系统稳定性都有好处。

最后再分享一条个人体会。视觉巡线这个项目，从能跑变成稳定跑，差距往往不在某一个模块多复杂，而在于每个环节的余量。图像识别留一点阈值余量，通信协议留一点校验余量，PID留一点调节余量，电源留一点压降余量，每个环节都松一点，整辆车就稳一大截。我一开始每个环节都卡着极限调，结果全链路一联动就开始共振、丢帧、乱抖，后来学会在每个关键参数上留出20%的裕量，许多问题自己就消失了。如果你的小车也遇到“单独调都行，连起来就废”的情况，不妨从余量的角度重新审视一遍每个环节。