碎碎念：这是我们组第一次参加电赛，把我在物联网学的那点玩意儿用了上去，最后比赛结果二等奖进了国赛也是很令我们欢欣鼓舞的。
参赛队伍需要设计并制作一辆无人驾驶小车，使其能够在模拟的室内环境中自主导航。可利用轮速计等传感器实现精准移动，以及通过摄像头识别二维码进行导航。
1．基本要求 （1）小车从 A 出发，在 B 点停止。完成时间不超过 30 秒。 （2）小车从 A 出发，途径 B 点、在 C 点停止。完成时间不超过 30 秒。 （3）在第（2）题基础上，在途中任意地点动态放置停车二维码（表 1），小车能做出正确响应，即：小车检测到停车二维码，立即停车；停车二维码消失后，小车继续前进；小车对其他二维码不响应。去除停车时间，完成时间不超过 30 秒。 2．发挥部分 （1）小车从 A 出发，按二维码指示进行导航，路线固定，路线如图 2 所示。完成时间不超过 60 秒。
（2）小车从 A 出发，按二维码指示进行导航，路线由裁判随机设定。完成时间不超过 120 秒。 3．创意部分 参赛队伍可以自由发挥，为装置添加各种相关特色功能。
（1） 小车尺寸（长宽高）必须 ≤27×20×25cm；小车运动方式不限，阿克曼、全向、四轮驱动、三轮车、二轮车、履带车等均可。
（2） 小车使用的嵌入式微控制器（微处理器）和硬件传感器，种类数量均无限制。
（3） 比赛时不能人为遥控或干预小车，小车需自主行驶。
（4） 每个测试项开始前，选手可以使用小车按键设置参数，使用按键启动测试；也可以使用 SSH、nomachine 等软件远程登录小车的操作系统，输入指令启动小车。小车启动后选手不能再接触小车。
（5） 二点之间的运动不要求直线。
（6） 途经某点、在某点停车的判断标准为：小车在地面上的投影完全覆盖或者部分覆盖地面上用于标识地点的圆形图案（直径 3CM 左右）。
（7） 小车途径某点，或者在某点停车，需给出声光提示。
（8） 二维码采用 Apriltag 的 36h11 类型，二维码尺寸 8CM 左右。二维码垂直于地面放置，二维码中心距离地面 15CM 左右，如图 3 所示。使用的 ID 及其含义如表 1 所示。
设计内容：
基于 OpenCV 视觉识别和 ESP32、STM32 嵌入式的无人驾驶小车自主导航与二维码导航
本次比赛我们最终决定的硬件架构：
如图，使用 ESP32-S3 和 STM32F107 微处理器组成双 MCU 结构，通过 ttl 串口进行通信
2. 核心器件选型论证
（1）ESP32-S3 核心优势
A.双核处理能力 ：1 个核心专用于摄像头数据采集（OV2640 的 1600×1200@30fps），另 1 核处理 WiFi 传输
B. 硬件加速优势 ：内置 JPEG 编码器，可将 RAW 图像压缩至 50-80KB/帧（节省带宽 40%），支持 802.11n WiFi，实测传输延迟<150ms（5 米距离）
C.接口适配性 ：DVP 并行接口完美匹配 OV2640，相比 ESP8266 的 SPI 接口带宽提升 5 倍。
（2）树莓派+OpenCV 方案优势
A.处理性能 ：树莓派 3B 的 Cortex-A72 所带来的 1.5GHz 远强于 OpenMV 的 Cortex-M7 的 480MHz 处理能力，并且价格比 OpenMV 的开发板相对低廉。
B.算法扩展性 ：支持 OpenCV 完整功能库，可后续扩展 SLAM 等高级功能。
（3）OV2640 摄像头优势
A.分辨率优势 ：1600×1200 远强于 OV7670 的 640×480。
B.自动对焦功能 ：支持动态焦距调整，适应不同场景。
3.其他方案分析：
方案 A：ESP8266 替代 ESP32-S3
可行性分析 ：
(1)带宽瓶颈 ：ESP8266 的 SPI 接口最大速率 40Mbps，传输 1600×1200 图像需要大约 0.7s/帧，仅 1.3fps，而 ESP32-S3 的 DVP 接口带宽可达 150Mbps，支持 30fps 传输。
(2) 内存限制 ：ESP8266 仅 160KB SRAM，无法缓存高分辨率图像帧。
结论 ：ESP8266 无法满足高清视频流传输需求。
方案 B：OpenMV 替代树莓派
| 参数 | 树莓派 3B | OpenMV H7 |
|---|---|---|
| CPU 架构 | Quad-core A72 | Single-core M7 |
| RAM 容量 | 4GB LPDDR4 | 1MB SRAM |
| AprilTag 识别延迟 | 25ms | 120ms |
| 多标签处理能力 | 同时识别 15 个标签 | 最多识别 3 个标签 |
| 功耗 | 15W@满载 | 1.2W@满载 |
可以看出，树莓派方案在识别精度和响应速度上具有显著优势，以及我们团队有树莓派的开发经验，可以更好更快的完成要求。
方案 C：OV7670 替代 OV2640：经过测试，OV2640 在 1 米距离识别成功率达 92%，OV7670 仅 65%，最终选用 OV2640 方案。
1.图像传输带宽分析
(1) 原始图像数据量计算：OV2640 传感器输出分辨率 1600×1200，RGB565 格式下每像素占 2 字节，单帧数据量：1600×1200×2 = 3840000 Bytes 约 3.66MB。
(2) JPEG 压缩效率验证：ESP32-S3 内置硬件编码器压缩率实测 50-80KB/帧，压缩比计算：80KB/3,840KB ≈ 2.08%，满足带宽节省 40%的设计目标。
(3) 无线传输需求验证：30fps 时带宽需求：80KB×8×30 = 19.2Mbps，802.11n 理论速率 150Mbps，实际有效吞吐约 70Mbps，余量系数：70/19.2 ≈ 3.65，满足实时传输要求。
2.AprilTag 识别性能分析
(1) 处理时延计算：树莓派 3B 检测延迟 25ms 。
(2) 多标签处理能力：树莓派并行处理能力：15 标签/(25ms×4 核) = 150 标签/秒
3.运动控制实时性验证
(1) 控制环路延迟分析：图像采集(33ms) + 传输(150ms) + 识别(25ms) = 208ms，转向执行时间 1.2s 包含 5 个控制周期，满足动态调整需求。
(2) 电机响应验证：
假设电机转速 300RPM，轮径 48mm
线速度 v=π×0.048×300/60 ≈ 0.754m/s
转向角速度计算：差速比 150:300 时，转弯半径 r=0.2m
角速度 ω=v/r ，大约为 3.77rad/s → 转向 90° 需时间 t=π/(2×3.77)，约为 0.42s
实测转向时间 1.2s 包含系统惯性补偿余量
4.系统稳定性分析
(1) 内存占用验证：
使用树莓派 3b+型号，在 4GB 内存下，OpenCV 进程占用约 500MB
MQTT 图像缓冲区设计为 20KB×30fps=600KB/s
内存利用率：600KB/(4GB×1024) 大约为 0.0146%
(2) 网络可靠性：
设计传输丢包率<5%时，采用 MQTT QoS1 保证传输，在重传机制下，有效数据传输间隔 Δt=1/30+0.15≈0.183s 满足控制周期要求
程序的流程图
1、测试目标：验证基于 AprilTag 的导航控制逻辑，重点测试标签识别准确性，速度控制与转向逻辑匹配性，急停标签响应，手动/自动模式切换。
用例 1：基础指令识别测试
| 测试动作 | 预期结果 | 实际结果 |
|---|---|---|
| 显示标签 1（直行） | 持续发送(left:300, right:300) | 符合预期，无偏差 |
| 显示标签 2（左转） | 发送(left:100, right:200)并保持 8 秒 | 持续 7.95-8.1 秒 |
| 显示标签 3（右转） | 发送(left:200, right:100)并保持 8 秒 | 持续 7.98-8.05 秒 |
| 显示标签 0（急停） | 立即停止(left:0, right:0)，直到标签消失 | 响应延迟<0.1s |
用例 2：复合场景测试
| 测试场景 | 预期行为 | 观测结果 |
|---|---|---|
| 左转过程中检测到急停标签 | 立即停止，转向计时重置 | 符合预期 |
| 右转 8 秒结束后无新指令 | 维持最后有效速度(300,300) | 持续直行 |
| 多个导航标签同时出现 | 优先执行第一个检测到的标签 | 按检测顺序响应 |
| 自动模式下手动输入指令 | 立即覆盖当前自动控制 | 模式切换延迟<0.3s |
用例 3：边界条件测试
| 测试条件 | 预期表现 | 测试结果 |
|---|---|---|
| 标签部分遮挡(>40%) | 不识别 | 遮挡 50%时失效 |
| 标签倾斜角度>60° | 识别率下降至 75% | 实际识别率 68% |
| 光照强度<50lux | 识别延迟增加 | 平均延迟从 0.2s→0.8s |
| 8 秒转向期间重复检测同标签 | 不重置计时 | 保持原计时 |
摄像头和 CV 视觉部分采用 QQVGA 分辨率（160x120）进行的实现，重点验证 分辨率对检测距离的影响 ， 低帧率（10FPS）下的控制响应 。，电机控制指令的平滑过渡 ， 优化后的系统稳定性 。
用例 4：分辨率适应性测试
| 测试条件 | 预期表现 | 实测数据 |
|---|---|---|
| 标签正对摄像头（0°） | 有效检测距离 0.3-1.2m | 实际 0.4-1.0m |
| 标签侧向偏移 30° | 仍可识别 | 识别率 92% |
| 动态移动标签（0.2m/s） | 连续识别不丢帧 | 平均丢帧率 3.2% |
本设计成功构建了基于视觉导航的无人驾驶小车系统，实现了二维码动态导航、多指令响应功能，基于 DCT 系数自适应的 JPEG 压缩策略，在保证识别精度的前提下，使无线传输数据量降低至原始数据的 2.08%，验证了图像分辨率 QQVGA 和 QVGA 与 10fps 与 25fps 的量化关系，确立 160x120@25fps 为最优平衡点，通过 UART 串口发送指令测试，实现控制逻辑与硬件驱动的解耦调试。
车子和控制：我们买的是套件，亚博 310 编码器电机的小车，淘宝链接，根据 esp32s3_car 文件夹下的.ino 文件将摄像头接好，将 gpio40 接到车子的 TX 针脚，41 接到 RX 针脚，用 arduino ide 将 esp32s3_car 的东西编译烧进 s3
MQTT 部分：docker 自行跑个 emqx，不细说，然后 Python 安装 opencv-python，flask，windows 安装 pupil_apriltags，linux 安装 apriltag，对应的检测器初始化部分就要进行修改
windows:
from pupil_apriltags import Detector
detector = Detector(families="tag36h11")Linux:
from apriltag import DetectorOptions, Detector
detector = Detector(DetectorOptions(
families='tag36h11',
quad_decimate=1.0, # 图像降采样系数
quad_sigma=0.0, # 高斯模糊系数
refine_edges=1, # 边缘细化
decode_sharpening=0.25 # 解码锐化
))最后直接一手 python mqtt.py 即可
The wrong ways:
1.高估了 8266 的处理能力，硬件方案失误了
2.低估了 esp32s3 的潜力，这个更多的是我们团队开发能力的问题
3.没有仔细阅读赛题，传感器用的太少，很多细节没有注意到
4.学校资源沟通较差，实验室周六日不开放也不说一声，笔记本锁里面整整两天，时间浪费过多。
5.没有考虑到车子的其他形态。
6.纯 CV 的方案是 MuWinds 设想的，可纯 cv 需要考虑很多细节，但我们考虑的太少。
The right ways：
1.OpenCV 是个正确的路线，但是需要我们长期磨合
2.及时更换到 esp32s3 没有死磕 8266，采用树莓派 opencv 通用性好方便调试
3.四驱车至少跑的稳健
感谢队友们：@EVGA2048和@GMRgemou，也感谢杨萍老师借我的 ESP32S3 板子！
0.没想到小小校赛竟不乏高手哈哈哈，被高手炸鱼啦，但个人对于二等奖还是很满意的，锻炼了个人处理突发事件的能力，以及对于团队协作，任务分配方面的新思考
1.前期队内任务分配协调失误，以及学校种种逆天操作，导致出现了过多罚时
2.四驱确实是个普遍方案，可以完成比赛，但信号传输及车轮配重带来的转向误差会累积，在测试时确实达到了一个比较离谱的角度
3.其他参赛组的专项方案确实给了我不少启发，例如动力轮和转向轮分离结构
4.mqtt方案本是时间紧迫下的产物，但最终反响不错，具有可行性
4.感谢能在大学期间认识你们，并且有过一段竞赛经历；也感谢你们作为大一新生，在军训和学校工作的压力下依然压榨时间熬夜开发
就这样吧，
致谢！