简介2024电赛捡球小车全套资料包专为电子设计竞赛备赛者与智能车开发爱好者准备目标是解决小车自动识别并捡取球体这一典型赛题需求。包内共344个文件主要以C语言工程为主包含142个头文件和97个源文件并配有少量汇编、Python辅助脚本以及Keil、IAR、CCS等主流IDE的工程配置整体大小仅5.44MB结构紧凑下载便捷。目前已有312人学习。资料内提供主控芯片初始化代码、电机驱动模块、传感器数据采集与处理逻辑、以及完整的系统主循环同时还附带临时文件清理批处理和备份文件方便反复调试与二次开发。通过这套资料读者能够快速搭建捡球小车的软件框架理解路径识别、避障与抓取控制的具体实现也可直接作为电赛赛前冲刺的参考模板。 2024年的电赛赛题里捡球小车算是关注度很高的一道综合题不少队伍都选了它。这个题目好就好在非常“全”——视觉识别、运动控制、机械结构、电源管理、无线通信全都能练到属于典型的“一套作品打通嵌入式主干技能”的题目。我手上的这套资料是从头到尾完整跑通的版本含机械图纸、控制代码、视觉识别脚本、调试记录和最终答辩PPT这篇文章就把整套方案的设计思路和落地细节拆开讲清楚给准备参赛或者想复现这套作品的同学一条可以直接走的路。1. 项目整体设计思路拆解1.1 赛题场景与任务目标的重新审视捡球小车这个任务表面上看是“把场地上的球捡起来运到指定位置”但放到电赛的真实场景里它其实是个由多个子系统耦合而成的闭环工程。场地通常是一个限定尺寸的矩形区域球的颜色固定多为橙色或白色网球位置随机且要求在限定时间内尽可能多地拾取并投放。这个题目的难点不在于某个单一功能特别复杂而在于所有子系统必须在有限的时间和功耗约束下协调工作。视觉识别慢了小车就会在同一个球附近反复犹豫机械结构卡球了再好的识别算法也白搭底盘电机响应不及时巡线和定位就会出现偏差。所以整个项目的设计逻辑必须从“目标拆解”出发倒推硬件选型和代码架构而不是东拼西凑攒一套能动的模型就完事。1.2 系统级架构与模块划分整个小车我拆成了五个核心模块视觉检测模块、主控决策模块、运动执行模块、拾取执行模块、电源管理模块。视觉模块负责“找球”主控模块负责“想”底盘电机负责“走”舵机与直流电机组成的拾球机构负责“抓”电源部分负责让整套系统稳定跑完比赛。模块之间采用清晰的分工协议通信视觉模块我这里用的 OpenMV处理好坐标信息后通过串口把归一化坐标和颜色标记发给主控STM32F407主控根据坐标数据做运动决策和PID计算输出PWM控制底盘运动。拾球机构的触发由主控根据“到位信号”判断——这个信号可以是视觉反馈也可以是车头限位开关两种方式各有优劣我这里最终采用的是双信号并联确认具体细节后面展开。这种分工设计的核心好处是降低联调难度。如果视觉和运动都在同一个芯片上跑算法一复杂控制周期就会被拖慢比赛现场出了问题也很难定位到底是视觉卡了还是底盘飘了。分开之后各模块独立调通再联调排错效率高很多。2. 视觉识别与目标定位的工程化实现2.1 识别方案选型为什么选 OpenMV 而不是树莓派很多队伍在这里纠结了很久到底是上OpenMV还是直接用树莓派加摄像头。我的结论很明确电赛场景OpenMV够用且稳定。原因有三第一OpenMV内置了完整的图像处理库颜色阈值识别这种基础功能不需要自己从零写开发效率高第二它自带硬件加速和固定帧率输出一个识别周期可以控制在20毫秒以内第三树莓派在电赛环境下的供电稳定性是个坎电流波动大一点就直接重启而且 Linux 系统启动和运行的开销在这类任务里是纯粹的浪费。当然OpenMV也有它的局限——算力有限跑不了YOLO这类深度学习模型。但捡球任务识别的目标颜色是预设好的环境光可控或者半可控传统CV算法完全够用而且推理速度快、逻辑可解释性好。比赛时如果球被遮挡或者光照异常也方便现场调阈值这点比黑盒模型更有优势。2.2 Lab颜色空间与阈值调试的关键细节OpenMV里最常见的颜色识别方式是LAB颜色空间的阈值二值化。L是亮度A是绿红色差B是蓝黄色差。识别一个橙色网球核心就是设定一个合适的LAB三元组范围把属于球的像素从背景里分离出来。这里有一个特别容易踩的坑**很多新手直接沿用网上的LAB阈值拿到现场发现识别率最低能掉到一半以下。**原因很简单不同场地的灯光色温和地面反射率完全不一样阈值是环境敏感的。我在调试时用的是OpenMV IDE自带的大津二值化阈值编辑器把现场拍到的每一帧图像导出来逐帧微调而不是一次性把所有场地都靠猜。为了从根上减少环境干扰我在硬件上还加了两个非常便宜但极其有效的改动。第一摄像头前加了一块偏振片能显著削弱地面反光第二把摄像头的曝光值固定住关闭自动曝光。自动曝光在这种场景下是灾难——小车转向时亮度突变曝光自己跳来跳去球的颜色直接被拉偏。固定曝光之后阈值一次调好基本能稳定打完整个赛程。2.3 坐标转化与目标给进策略视觉识别只是第一步更关键的是把小球的图像坐标转化成底盘可以执行的运动指令。我的做法是把图像中心点和目标球的像素坐标做偏差计算偏差值经过归一化后通过串口发给主控。主控端收到的是一个范围在-1到1之间的横坐标偏差和距离估计值。这个方案比直接传输绝对坐标更稳因为归一化消除了不同分辨率下的坐标漂移问题主控只需要关心“球在视野左侧还是右侧”以及“大概多远”剩下的细节交给运动控制去收敛。实测下来整个识别和控制闭环的延迟在100毫秒以内对于一个移动速度不超过0.5m/s的小车来说完全足够。还有一个经验是给视觉模块加入“目标丢失回溯”机制——如果连续3帧找不到球就自动切换为重扫模式主控按预置的S形路径扫描场地而不是原地傻等。很多队伍的代码在目标丢失后进入死循环或者乱冲这个问题在比赛现场非常致命。3. 机械结构与拾取装置的选型和调优3.1 底盘构型三轮全向和四轮差速的取舍底盘我对比过三轮全向轮和四轮差速两种主流方案。三轮全向的优点是运动灵活可以实现平移捡球时对位精度要求可以放宽一点缺点是控制算法复杂全向轮对地面平整度非常敏感稍微卡一下就会丢转速反馈。四轮差速的优势是稳定、结构简单、控制逻辑明确用传统的双路PID就能跑得很好缺点是转弯半径大车头必须对准球才能完成拾取这对视觉定位和控制精度提出了更高要求。考虑到比赛场地是平整的硬质地面且拾球机构是从车头伸出的最终我选了四轮差速底盘。原因很简单——机械可靠性优先视觉定位精度的短板可以通过后面的“双信号到位确认”机制来弥补。四轮差速如果跑偏了PID参数一调就回来但全向轮如果某个轮子卡死排查起来会非常痛苦。3.2 拾球机构的三个关键设计约束拾球机构是整台车机械设计里最讲究的部分它决定了“看得到球”能不能变成“抓得到球”。常见的方案有三种滚刷式、铲斗式、夹爪式。我采用的是前铲滚刷组合式因为这种结构对球径的容错范围最大网球稍微有点大小差异也不容易卡死。设计时有三个关键约束必须同时满足入口宽度要略大于球径但太大又会降低对准精度要求导致球从侧边滑出去。我这边入口留了 1.2 倍球径的余量。滚刷转速和车速需要匹配。滚刷转速太低球送不进储球仓转速太高球会在入口弹跳。我通过一组实验测出了最佳车速是 0.3m/s、滚刷PWM占空比为 65%这个组合下拾取成功率最高。储球仓容量决定了单趟回收的数量。我做的是4球仓容量再大机构重心会明显后移影响底盘稳定性。比赛规则通常也是分多次运输4球仓刚好能覆盖单程效率。3.3 舵机安装与重心控制的实操血泪这个部分是我调试过程中栽过跟头最多的地方。第一次装机时为了追求结构紧凑我把舵机装得过于靠前导致前轮负载过大转向响应非常迟钝。后来重新设计了电机支架把舵机往底盘中心方向移了 3 厘米问题立刻缓解。重心控制原则其实很简单**整个机械系统的重心应该落在底盘的几何中心附近偏差不超过2厘米。**否则在急加速或者紧急制动时车体会出现明显的抬头或点头轻则影响视觉稳定重则直接把储球仓里的球颠出来。另外有一个细节非常值得注意——所有运动部件的固定螺丝都要加弹垫或者螺纹胶。电赛现场的场地看起来平整但小车高速跑动时振动其实非常剧烈我比赛过程中就亲眼见过旁边的队伍车上掉出来一颗螺丝。这种问题赛前不查现场只能干瞪眼。4. 主控逻辑与运动控制的核心实现4.1 主控选型与代码框架主控我选择的是STM32F407理由不外乎三点主频够高、外设丰富、资料成熟。捡球小车需要同时处理串口数据接收、双路电机PWM输出、舵机控制、状态机切换F407的资源和性能都绰绰有余。代码框架我按电赛的惯例采用前后台系统一个10ms定时器中断做控制循环主循环里做状态机跳转和串口数据处理。不跑RTOS不是因为RTOS不好而是这种任务复杂度用前后台系统已经足够而且出问题的时候调试更直观。中断里只做最核心的PID计算和PWM更新所有耗时操作全部放主循环避免中断阻塞。4.2 双路PID闭环速度环与转向环解耦运动控制的核心是双路PID——一路负责车速稳定一路负责转向跟随。这里最关键的工程经验是速度环和转向环必须解耦否则车在转向时速度会被拖慢追球过程就会变得一顿一顿的。我的做法是速度环的输出作为转向环的基准值转向环根据视觉偏差动态调整左右轮的速度差。具体来说就是先通过编码器反馈做速度闭环让两个后轮的转速稳定在目标值附近然后根据视觉模块传来的横向偏差在速度基础上叠加一个转向修正量。转向修正量和偏差大小成比例并且限定最大修正幅值防止小车在目标点附近振荡。PID参数我用的是工程上最常见的凑试法先只调P让系统不振荡再加I消除稳态误差最后加一点D改善动态响应。捡球场景下最终的参数大致是 P1.6、I0.02、D0.15这个组合在硬质地面上表现比较均衡。注意这些参数强烈依赖车重和轮胎材质换套轮子就必须重调。4.3 主从串口协议设计一个字节辨识方向主控和视觉模块之间的串口协议我设计得非常简洁——一帧5个字节分别是帧头0xA5、颜色标记、归一化横坐标、距离等级、校验字节。其中横坐标范围映射为 0-255中间值127表示球在正前方距离等级分近、中、远三档对应不同的车速策略。协议越简单越不容易出错这个原则在电赛现场体现得淋漓尽致。不少队伍用了复杂的JSON格式或者带上位机协议联调时半天对不上字段我在旁边看着都替他们急。嵌入式设备之间的通信只要能表达清楚状态和控制量越简单越好省下来的时间全都可以用在可靠性测试上。4.4 状态机设计搜索、对准、拾取、运输、投放整套小车逻辑我拆成了五个状态搜索、对准、拾取、运输、投放状态之间通过明确的事件标志切换。比如“对准”状态的进入条件是视觉横坐标偏差小于阈值且距离达到近档“拾取”状态的进入条件是车头限位开关被触发且视觉确认球已经进入滚刷范围。双信号确认是我认为整个逻辑设计里含金量最高的一个细节。如果只靠视觉球被滚刷挡住后容易丢失目标如果只靠限位开关又可能在空跑时误触发。只有两者同时满足才认为“球已到手”再切换状态。这个机制几乎没有额外成本却让整套系统的稳定性提升了一个台阶。5. 电赛现场常见问题与排查技巧实录5.1 高频Bug排查速查表比赛现场最容易出的问题很多都不是什么高深技术问题而是一些“看起来莫名其妙”的小毛病。我整理了一个排查速查表参赛前可以逐条对照检查故障现象可能原因排查方法小车跑起来不走直线左右轮PWM基准不一致或轮胎磨损空载测轮速重新校准占空比视觉识别时好时坏自动曝光未关闭或现场反光变化固定曝光调整阈值并加偏振片舵机有抖动电源纹波过大在舵机电源端并联470uF电容串口数据乱码波特率不匹配或共地问题检查两端配置确认物理共地球到了滚刷却不进仓滚刷转速和车速匹配不当参照前述占空比参数重新匹配储球仓漏球仓口挡板高度不足加高挡板或调整仓口倾斜角电池电压骤降导致复位线径太细或电池放电倍率不足更换AWG16以上硅胶线选高C数电池小车到目标点来回振荡PID的D项过小或I项过大增大D项至轻微过冲再回调5.2 解决一个隐蔽的电源干扰问题在第二次联调时我遇到过一个特别隐蔽的问题——只要舵机一动作串口数据就会出现偶发乱码。用示波器测量后发现舵机启动瞬间电源线上会出现将近1V的毛刺直接干扰了串口芯片的参考电平。排查过程持续了一个上午最后定位到是舵机电源和主控电源共用了一条太细的供电线。解决方案是第一把舵机电源单独走一路并在舵机供电端并联一个大容量电解电容吸收瞬时压降第二串口线换成双绞屏蔽线并且保证主控和视觉模块良好共地。改完之后问题彻底消失。5.3 现场环境变化后的快速应对策略电赛现场的光照条件和赛前调试环境通常有差异所以赛前必须准备好“临场微调三件套”——视觉阈值配置文件、串口调参指令、和应急代码备份。我和队员在现场每换一个场地第一件事就是拍一张场地照片然后花两分钟时间重新拉一下LAB阈值范围确认没有大面积误检之后再跑正式流程。这个过程一定要提前演练到“肌肉记忆”级别。比赛当天紧张情绪不可避免如果连阈值调整工具都不熟悉很容易在关键时刻慌神。我见过太多队伍在预赛环节因为没来得及调阈值直接丢分这不是技术不行纯粹是现场应急流程没准备。6. 资料包的核心内容与后续扩展思路6.1 全套资料里应该包含什么一套真正能称为“全套资料”的捡球小车项目光有代码是不够的。我整理资料时按以下结构打包机械结构完整三维模型源文件、二维工程图、BOM物料清单包含采购链接和替代料硬件电路主控原理图、PCB、电源板设计文件嵌入式代码STM32工程完整源码含状态机、双路PID、串口协议解析视觉代码OpenMV工程代码、阈值调参说明、现场快速标定脚本调试记录从组装到完赛的完整调试日志记录了关键参数变化和异常处理演示资料答辩PPT、系统框图、效果演示视频、技术说明书资料的价值不在于文件数量多而在于能不能让别人在不看原作者的条件下也能完整复现并理解每个设计决策。6.2 这套框架还能扩展出哪些玩法捡球小车这个项目虽然是个竞赛题目但它本质上是一个完整的机器人平台换掉执行末端和识别目标就能衍生出很多其他项目。把OpenMV换成带深度相机的处理板配合传统CV识别障碍物就能做成简单的自动驾驶避障小车把滚刷机构换成机械臂或者电磁铁就能应对不同形状的物体搬运任务把运动底盘换成麦克纳姆轮再加上一个建图算法就变成了简单的SLAM演示平台。我经常跟同学说电赛作品不要做完了就锁进柜子里这套硬件平台完全可以作为后续课程设计、毕业设计甚至开源社区项目的底座。很多做ROS的同学还很羡慕小车上有完整的前后端通信和运动控制实现这本身就是一笔可复用的技术资产。6.3 备战电赛的几条个人心得带了这么多年的竞赛项目我越来越觉得电赛拼的其实是系统工程的成熟度。把每个小模块做扎实、留好接口、备好应急方案比追求某方面的极致性能更重要。视觉识别准确率做到95%之后再花大量时间去提升到98%收益其实远不如把那一套现场调参流程和故障排查方案准备到位。另外就是一定要留出足够的时间做“整机老化测试”。连续跑30分钟看会不会过热、电池掉电比是多少、紧固件会不会松脱这些指标没有一项是能靠临时抱佛脚解决的。我们比赛前一周做的就是反复跑、反复记录、反复调这才是项目真正从“能跑”走向“能赢”的关键阶段。本文还有配套的精品资源点击获取