简介：这是一份基于树莓派与Python的OpenCV视觉小车项目资源，适合机器人爱好者、树莓派玩家以及学习计算机视觉的初学者。资源围绕颜色识别、巡线行驶与物体跟随三个核心功能展开，利用USB摄像头实时采集图像，通过cv2.inRange设置颜色阈值提取目标区域，再结合边缘检测与跟踪算法控制小车运动。压缩包内含2个文件，包括1个py格式的Python脚本和1张png示例图片，共109KB，脚本封装了主要视觉处理与控制逻辑，图片可用于阈值调试与效果对比。目前已有10503人学习下载，说明该方案受到不少实践者关注。通过这份资源，读者可以快速跑通树莓派视觉小车的核心流程，掌握颜色空间转换、阈值过滤和PID控制等关键思路，为后续扩展更复杂的自动驾驶或智能跟随项目打下基础。 拿到这个树莓派python+opencv颜色识别、跟随、巡线小车.zip的时候，我心里大概就猜到它是一套什么样的工程了。压缩包命名把这台小车的能力边界写得明明白白：颜色识别是它的“眼睛”，跟随与巡线是它“大脑”要输出的两种行为模式。在很多课程设计和竞赛项目里，这几乎是视觉小车绕不开的三件套，能把这个工程完整跑起来，OpenCV的基础算真正落地了，而不是停留在对着文档调函数。
这篇文章我就用实际部署和调参的视角，把这个项目从头到尾拆开讲。不谈空洞原理，只聊我在复现这类工程时怎么选硬件、怎么配环境、怎么写识别逻辑、怎么调 PID，以及那些文档里不会写的坑。不管你是拿它做毕设，还是想给竞赛做个地基，都可以照着动手。
1. 拆箱这个项目：一台视觉小车的完整闭环
1.1 颜色识别、跟随、巡线，三者到底是什么关系
先说清楚这台小车要完成的三件事。颜色识别是基础视觉能力，目标是“在画面里找到某个颜色区域并定位它”；跟随是在颜色识别的基础上往前走一步，让小车始终跟着目标色块走，相当于一个“动态追踪”；巡线则是把视觉能力用在路径规划上，让小车沿着地面上的线跑，线的颜色和背景形成强对比，本质也是一种颜色识别。
很多新手容易犯的错，是把这三件事当成三个独立项目来做。实际上它们的框架完全一样：摄像头采集图像 → OpenCV处理 → 提取目标坐标或偏差 → 输出给电机控制。区别只在“处理图像”这一步的侧重点不同。理解了这条链路，后面再改功能就只是改中间一环的事。
1.2 这个项目适合谁，又能学到什么
如果你是刚接触树莓派和OpenCV，这个项目是非常合适的“第一辆完整小车”。它不涉及深度学习模型，不需要GPU，算法逻辑肉眼可读，出错了能一步一步排查。如果你已经有基础，它也值得做，因为把一个识别算法稳定地跑在嵌入式平台、并且跟上实时控制，和电脑上写Detect脚本完全是两回事。
从技术栈上看，做完这个项目你至少能收获这些：树莓派的环境配置和引脚控制能力、OpenCV的核心图像处理流程（颜色空间转换、阈值分割、轮廓提取）、PID控制的直觉理解、以及一套完整的“感知→决策→执行”嵌入式系统设计思维。这些能力在自动驾驶小车、无人机悬停、智能物流分拣等项目里全部用得上。
2. 硬件选型与接线：这板子选错了，算法再漂亮也跑不动
2.1 树莓派选型：4B是最稳的“甜点位”
项目里写的是“树莓派”，但具体用哪个型号差别很大。我的建议是首选树莓派4B（2GB或4GB内存版本），原因很朴素：性能够用、资料最全、散热方案成熟。4B跑OpenCV进行VGA分辨率的实时处理，CPU占用率大概在40%到60%之间，还能余出资源给控制逻辑。现在树莓派5也出了，性能当然更强，但价格高、散热需求更苛刻，部分老款摄像头和扩展板的兼容驱动还需要适配，如果你不是在性能上有直接需求，没必要一上来就用5。
至于树莓派Zero系列，除非你想做超小型车，否则别碰。它的算力跑实时颜色识别实在太勉强，帧率掉到十几帧以下，控制延迟会非常明显，小车开起来是“一顿一顿”的。
2.2 摄像头与驱动板：OV5647和L298N是黄金搭档
摄像头不用纠结，树莓派官方推荐的OV5647（也就是常见的树莓派Camera Module）最省心，驱动内置在系统里，插上排线就能用。传感器尺寸不大，但颜色识别的需求完全够用。要注意的一点是排线的插入方向，金属触点要朝向没有元件的那个方向，插反了系统检测不到设备。
电机驱动板我用得最多的是L298N。它皮实、便宜，能同时驱动两个直流电机，自带5V稳压输出可以给树莓派辅助供电。接线不难，但需要注意的是逻辑输入端的电平——L298N的逻辑电压和电机电压不是一回事，IN1到IN4接树莓派的GPIO口，ENA和ENB两个使能端用来控制PWM调速，这两个口必须接，否则电机只会要么全速转、要么干脆不转。
2.3 供电链路：这是整个项目最容易翻车的环节
很多人的小车跑飞或者树莓派随机重启，问题都出在供电上。电机启动瞬间的电流冲击非常猛，如果电池同时给树莓派和电机供电，电压会被瞬间拉低，树莓派直接掉电重启。
我的做法是双电源方案：一组18650电池给L298N和电机供电，一组5V移动电源或降压模块单独给树莓派供电。两个电源的地线要接在一起（共地），这样PWM控制信号才有参考电压。注意，是只接地线，不要把两组电源的正极并起来。如果你的电池组太弱，电机一启动就掉压，可以适当串联一个大电容在电机电源两端，能明显缓解瞬态压降。
3. 环境搭建的最大分水岭：树莓派上安全装下OpenCV
3.1 系统与换源：别小看这一步，能省你几个小时
系统层面我建议直接用树莓派官方的Raspberry Pi OS（64位，Bookworm或更新版本），不要用Ubuntu for Pi。官方系统的硬件支持和摄像头驱动最好，OpenCV在ARM平台上的安装包也齐全。装完系统第一步是换源，这一步在国内网络条件下几乎等于必做项，不然后续apt install的下载速度会让你怀疑人生。
换源改/etc/apt/sources.list和/etc/apt/sources.list.d/raspi.list，把默认源替换为清华源或阿里源。注意确认你的系统版本代号是 bookworm、bullseye 还是 buster，源地址里的版本代号必须对得上，否则会报 404。替换完成后执行sudo apt update，如果出现红色报错，基本上就是版本代号写错了。
3.2 安装OpenCV：能pip就不要编译
树莓派上装OpenCV有两条路：pip install opencv-python直接装预编译包，或者从源码编译。我的建议非常直接：除非你有特别需求，否则永远不要选择编译，这不是潜能挑战，是在浪费时间。在树莓派4B上从源码编OpenCV，顺利的话也要3到4个小时，中间还可能因为内存不足而 OOM 失败。
使用pip安装（记得用虚拟环境或者加--user，不要污染系统级Python环境），几分钟就能装好。装完后立刻确认版本：
python3 -c "import cv2; print(cv2.__version__)"只要这里能输出类似4.9.0之类的版本号，就说明OpenCV已经可用。如果报ModuleNotFoundError，检查一下你是不是在同一个Python解释器环境下安装和执行，终端里which python3和which pip3必须指向同一个路径。
3.3 安装过程的三处常见报错
我遇到过的典型报错有三个。第一个是ModuleNotFoundError: No module named 'cv2'，原因99%是pip安装到了用户级目录而运行脚本时没带对应环境变量。第二个是numpy版本冲突，新版OpenCV对numpy版本有下限要求，安装时最好一起升级numpy。第三个是缺少GUI依赖，如果你用的是OpenCV的cv2.imshow，在树莓派桌面环境下没问题，但如果你用SSH命令行远程跑脚本，没有桌面环境时imshow会直接报错，这时候把图像保存到文件再查看，或者老老实实接一个屏幕。
4. 颜色识别不是“简单看颜色”：HSV阈值体系与轮廓过滤
4.1 为什么用HSV而不是RGB
颜色识别部分，新手最容易踩的坑是直接拿RGB做颜色判断。RGB是给显示器准备的色彩空间，它对光照变化极度敏感——同一个红色物体，在阳光下和阴影里拍出来的RGB分量可能差了十万八千里。而HSV把颜色的色相（H）、饱和度（S）和明度（V）分开，我们关心的颜色属性集中在H通道，光照变化主要影响V通道，所以按H通道做阈值分割，稳定性会好很多。
转换代码很简单：
# 读取图像后从BGR转到HSV hsv = cv2.cvtColor(frame, cv2.COLOR_BGR2HSV)然后你需要为每种颜色确定一组阈值，用cv2.inRange生成二值掩码：
# 例如红色在HSV中的阈值（跟具体红光环境有关，需要现场标定） lower_red = np.array([0, 100, 100]) upper_red = np.array([10, 255, 255]) mask = cv2.inRange(hsv, lower_red, upper_red)关键提醒：红色的H值在0附近，绕了一圈，所以纯红色往往要两组阈值拼接才完整，一组覆盖0到10，一组覆盖170到180，最后把两个mask用cv2.bitwise_or合起来。
4.2 形态学处理与轮廓提取的先后顺序
拿到mask之后不要急着找轮廓。mask里通常有大量噪点，你也不想把画面里一小块反光当成目标色块。我的标准流程是：先做一次中值滤波消噪，再做一次开运算（先腐蚀后膨胀）去掉离散小点、恢复目标边缘，最后做一次闭运算（先膨胀后腐蚀）填补目标内部空洞。
处理干净之后才轮到cv2.findContours。这里有个非常典型的版本坑：OpenCV 3.x及以后版本，findContours返回两个值（contours, hierarchy），而OpenCV 2.x返回三个值（image, contours, hierarchy）。树莓派上装的新版OpenCV基本都是三个参数接收：
contours, _ = cv2.findContours(mask_clean, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)RETR_EXTERNAL表示只取最外层轮廓，避免目标内部还有小轮廓干扰。这一步做完，基本就能拿到画面里所有“疑似目标”的轮廓了。
4.3 面积过滤是排序逻辑真正有效的前提
找到轮廓之后，不要上来就取最大轮廓（虽然在单目标场景里通常没问题）。低概率出现的反光噪点轮廓可能面积很大，直接取最大会导致目标跟丢了。我的经验是先做一个面积门槛，过滤掉过小的噪点轮廓，再在剩余轮廓里找最大的：
valid_contours = [] for c in contours: area = cv2.contourArea(c) if area > 500: # 这个阈值按实际图像分辨率调整 valid_contours.append(c) if valid_contours: target = max(valid_contours, key=cv2.contourArea) x, y, w, h = cv2.boundingRect(target) # 目标中心坐标 cx = x + w // 2 cy = y + h // 2面积阈值到底取多少，跟你摄像头的分辨率和距离有关。我的经验是先用一张包含目标的测试图，把实际目标的像素面积打印出来看一眼，再定阈值，千万不要拍脑袋写死。
5. 巡线核心：从二值化到“偏差值-PID”闭环
5.1 ROI区域：不要看整幅画面
巡线要解决的第一个问题是“线在哪里”。如果让算法处理整幅图像，远处的背景、地面的反光都会成为干扰，计算量也大。标准做法是设置ROI（感兴趣区域），让算法只看画面下方的一条带状区域——因为车头前面的地面才是巡线需要的信息。
实际操作中我会把画面下半部分切出来：
height, width = frame.shape[:2] roi = frame[int(height * 0.5):, :]然后对这个区域做灰度化、二值化（或者在色彩空间里直接提取线的颜色），得到一张只包含“线”和“背景”的二值图。
5.2 加权重心：经典且稳定的巡线误差计算
拿到二值图后，核心任务是算出“线相对小车中心偏了多少”。最粗糙的做法是找线的轮廓然后取质心，但更稳的做法是用“列加权重心法”。
思路是这样的：把二值图按列统计白色像素的数量，每个列坐标用它对应的像素数量作为权值，计算加权平均位置。这个位置就是线的“视觉重心”。然后与图像中心列做差，得到偏差值 error。
col_sum = np.sum(binary_img, axis=0) # 每个列的白色像素总数 total = np.sum(col_sum) if total > 0: weighted_x = np.sum(col_sum * np.arange(width)) / total error = weighted_x - width // 2 else: error = None # 没看到线，另做处理这个方法的妙处在于，计算量极小，但在绝大多数巡线场景中非常稳定，而且对线上有小缺口不敏感——因为一个缺口只影响一列或少数几列，整体重心不会有太大跳动。
5.3 PID参数调整：从调大Kp开始
偏差算出来之后，小车怎么转向就是经典PID问题了。巡线小车上最常用的简化版就是“P控制”加一点“D控制”：
output = Kp * error + Kd * (error - last_error)output直接作为左右电机速度的差值：左电机 = base_speed + output，右电机 = base_speed - output。这样车就会自动朝线的方向拐。
调参我的经验顺序是这样的：先把Kd设成0，只调Kp。Kp从小往大加，直到小车在线两边出现轻微来回摆动（振荡），说明Kp已经偏大，往回调一点到临界值的70%到80%。然后加Kd，抑制摆动，让车走直线更平滑。注意error是像素单位，不同分辨率下数值范围不同，Kp没有“标准值”，只能根据你的画面分辨率实测。我常用的起步值是，宽度640的画面里Kp = 0.5到1.5，然后逐步试。
巡线的问题情境有几个常见“变种”：十字路口（线交叉，重心会跳到另一条线上）、断线（线缺失，总权重为0）、急弯（线超出ROI范围）。处理上，十字路口可以加状态判断，比如连续N帧检测到总权重值超过某个阈值就认为是交叉口并直行；断线就保持上一帧的转向输出一小段，直到重新看到线。这些逻辑不复杂，但需要你想在“小车实际跑起来之后”再补，纸上规划再多也不如实地调两圈来得直观。
6. 跟随模式：把颜色识别结果变成电机的油门和方向盘
6.1 跟随的逻辑，其实只有一句话
跟随模式的本质是：目标在画面里的位置决定了小车怎么走。具体拆解成两个控制量：目标中心在画面中的横向偏移，决定了转向；目标在画面中的面积大小，大致反映了距离，决定了速度。
前面颜色识别部分我们已经拿到了目标外接矩形和中心点坐标(cx, cy)。横向偏差用cx - width//2来计算，负值代表目标在左边，正值在右边。转向控制跟巡线一样用PID，唯一区别是巡线的输入是二值图像的列重心，这里的输入是目标框的中心坐标。代码上几乎可以复用同一种PID逻辑。
速度控制的逻辑是：目标面积越大说明离得越近，就应该减速；目标面积越小说明离得越远，就应该加速追上去。这个比例关系不一定是线性的，我用的是分段处理：
if area < min_area: speed = base_speed # 太远，全速追 elif area < max_area: speed = int(base_speed * (1 - (area - min_area) / (max_area - min_area))) else: speed = 0 # 太近了，停住这个逻辑能保证小车在目标突然靠近时不会一头撞上去。
6.2 双电机差速与云台舵机的配合
跟随模式在实际开车时，转弯半径往往比巡线更剧烈，因为目标可能跑到画面边缘甚至出画。直接把转向输出叠加在左右轮速度上是常用方案，但如果转向差值太大，内侧轮可能变成反向转动，这时候要注意电机驱动的PWM值和方向引脚配合，别让某个轮子“抱死”。
如果你用的是带云台的舵机（通常两个，一个水平一个垂直），跟随逻辑会分成两层：底盘负责进进退退，云台负责一直把目标锁在画面中心。这样底盘可以只用速度控制，极大地简化了控制逻辑。我在做这些项目时经常感慨：把视觉目标锁定问题交给云台，底盘只负责纵向运动，整个代码的控制复杂度能降一半。舵机的控制用树莓派的硬件PWM，GPIO.PWM的频率通常设置在50Hz，占空比在2%到12%之间对应舵机的角度范围，这块必须跟你的舵机型号匹配，别直接照抄网上的数字。
6.3 目标丢失后的行为设计
跟随模式跑起来一定会遇到目标跟丢的情况，不处理的话小车的反应会很诡异——要么原地打转，要么加速乱跑。我的处理方式是做一个“丢目标计数器”：连续一帧没识别到目标，就把计数加1；识别到就清零。计数超过一个阈值（比如10帧）就停车或者原地小范围搜索。这个阈值设置的逻辑很关键，太短会频繁停车，太长则丢失后反应迟钝，实测下来10帧左右在30fps下是很舒服的节奏。
7. 我踩过的坑与扩展方向
7.1 三个最让我头疼的问题
第一个坑是光照变化。上午调试好的颜色阈值，下午换个角度太阳光一照就失灵了，原因就是HSV里我们只锁定了H和S阈值，V随光照变化极大。解决办法有两种：要么在阈值上放宽V的范围，要么在代码里先做一次自动白平衡处理，比如用OpenCV的cv2.xphoto.createSimpleWB().balanceWhite()。效果更好但计算量也会大一点。
第二个坑是OpenCV版本和代码惯性思维。网上大量代码是为OpenCV 2.x或3.x写的，你看它的findContours接收返回值的写法就能猜出年代。树莓派新环境装的是4.x，API变了，照着老代码抄必然报错。遇到这种问题别急着怀疑环境，先去看OpenCV的官方文档或者查一下版本的Release Notes。
第三个坑是PWM波输出不稳定。树莓派本身是跑多任务操作系统的，不是实时系统，软件PWM在高负载下会出现抖动，导致电机忽快忽慢。解决办法是把Python的控制线程优先级调高、尽量精简主循环里的工作量，或者干脆用树莓派的Pico等单片机来做电机底层控制，树莓派只负责视觉和决策。很多成熟项目都是“树莓派算眼睛，单片机跑腿”，这个架构跑起来质感完全不一样。
7.2 这个项目还能往哪些方向扩展
这套工程跑通之后，可以扩展的方向很多。你觉得颜色识别太“初级”，可以往目标检测升级，比如在树莓派5上部署轻量化的YOLOv5模型，反正树莓派5的算力比4B强不少，这个方向很值得一试。你想让识别更智能，可以做颜色标签的多目标识别，对不同颜色赋予不同的“任务”含义，比如让小车看到红色停、看到绿色走。你还可以做HSV自适应标定。不要手动设死H阈值，而是放一段“标定模式”的代码，把摄像头对准目标，程序自动统计H通道的分布，自动算出阈值区间，这样换场景之后重新标定一下就行，不用一行行改代码。
从更长远的工程角度说，等你在树莓派上把OpenCV的视觉链路、电机控制、PID都跑明白，完全可以把这个方案迁移到更复杂的平台上——无人机悬停需要类似的目标锁定逻辑，智能车竞速需要类似的巡线PID，机械臂视觉抓取需要类似的颜色定位。这个项目交付的不是一段可运行的代码，而是一种很通用的“感知-决策-执行”的工程直觉。
最后分享一个调试经验。这类视觉小车项目调试的时候，千万别直接上电整车调。先把摄像头固定在桌上，把目标物体放在不同位置，单独验证视觉识别和坐标输出；确认坐标稳定后，再把小车架起来（轮子悬空），验证电机和PID输出能让轮子往正确方向转；最后才放地上跑。每一层都跑通了，再叠加下一层。一层没调好就去试整车，你会同时面对视觉、控制、机械三个问题混合在一起，哭都来不及。按这个顺序来，这辆小车大概率一天之内就能从“平地翻车”变成“稳稳当当地追着红球跑”。
本文还有配套的精品资源，点击获取
