META

选型 / 2025.01–03：先找到旧机器的限制

2025 年 1 月 11 日的上海选拔赛结束后，队伍复盘了沿用上次国赛方案的机器。它已经能够参加比赛，但整机把视觉处理、动作处理和主控决策集中在一块 OpenMV 固件主板上。STM32H7 需要在同一段计算时间里处理图像、判断动作和通信；继续增加算法，首先遇到的并不是新功能怎么写，而是这些任务还能否及时完成。

结构上的代价同样具体。电池藏在上层板内部，更换要先拆板；二层板上的四个超声传感器、两个摄像头和线束又挡住了主板按钮。回合紧凑时，换电和按键操作会直接占用准备时间。延长摄像头排线产生的噪点也让团队看到，识别稳定性同时取决于算力、布线和安装方式。

团队先评估熟悉的双 OpenMV Mini 配 210 度镜头方案，再选择可运行 Linux 和标准 Python 的 MaixCam 作为下一阶段验证对象。四个 MaixCam 是当时的规划，不能据此把旧机器写成已经完成的四摄方案。本阶段的意义是确定系统拆分方向：让视觉协处理器输出目标信息，主板把资源留给动作与决策。

原型 / 2025.03–04：MaixCam 的速度与系统瓶颈

2025 年 3 月 24 日，采购的 MaixCam 和 120 度镜头到货。这个平台吸引团队的地方，是 Linux、标准 Python 以及 OpenCV、Numpy 等工具的可用性。相比在微控制器环境里自行补齐算法库，它让视觉开发更方便，也为将结果通过串口交给主板提供了新的分工方式。

到货后的第一件事却是修改支架。原支架尺寸偏小、底座不稳，必须先修正安装，算法测试才有可靠前提。色块识别移植比较顺利，日志记录单项测试达到 60 FPS 以上；但这个结果不能代表所有 OpenMV 算法都能同样加速，接下来的视觉测距很快暴露了差别。

在 320×240 图像上，原有线段检测不足 5 FPS。日志的排查发现，相关函数调用 OpenCV 的 CPU 路径，并没有因为平台存在 NPU 就自动利用加速。团队裁掉低价值区域，缩小处理范围，单项实验约提高到 10 FPS；又把 Canny 与霍夫变换拆开检查，增加阈值和最短线段等可调参数。

定位方面，ToF 被用作过渡方案。黑色墙面、斜入射和器件批次差异会让读数波动，甚至把局部遮挡误当成场地墙面。团队利用对侧距离之和与场地尺寸的关系判断异常，再选择较可信的一侧修正坐标。它能改善部分情况，但当相对两侧都被遮挡时，坐标仍会混乱，因此 LiDAR 被确立为后续方向。

结构也随之改变。维护困难的外壳被 50mm 铜柱支撑替代，电池方案从抽屉式快拆改成可从侧边放入。新增传感器并不是只占一个孔位：UART 接头、摄像头可调角度、树莓派尺寸和前方盘球机构都会争夺空间。早期 LiDAR / 树莓派布局甚至因遮挡前摄像头而回退。

三个任务同时运行后，色块识别、视觉测距和通信开始争用 CPU。日志中的 threading 尝试让视觉测距降至约 1–2 FPS，改为 multiprocessing 后约为 3–4 FPS。独立进程带来改善，但不是所有开销都会消失，图像处理、数据传输和操作系统调度仍然要付出成本。

团队随后发现色块识别还有 40 FPS 以上的余量，于是主动将它限制到约 30 FPS，把处理时间留给更慢的边缘检测。最终多任务实验中的视觉测距达到 5 FPS 以上。这个数字与前面的单项 10 FPS 属于不同测试条件，不能拼成一个“整机十帧”的结论。

运动层的 GoV 则把平移方向、机器人朝向和速度分开表达，并利用指南针 PID 减少走偏。传感器给出位置之后，还需要正确的轮组运动学和方向反馈才能转成动作。硬件测距与控制代码在这一阶段开始形成闭环，而不再是互不相干的演示。

集成 / 2025.04：四路摄像头围绕一块计算板工作

2025 年 4 月 10 日的日志提出一个新的问题：MaixCam 的传统视觉性能有限，而新增 LiDAR 又带来大量数据。继续寻找更强的边缘摄像头会受到价格与体积限制，团队于是选择社区和文档较完整、CPU 性能更强的树莓派 5，让相机负责采图、计算板集中处理。

镜头选择同样经过取舍。树莓派有 CSI 接口，但双摄超广角方案会带来明显畸变与视角问题。最终四路 USB 摄像头配约 130 度镜头，既增加方向覆盖，也把多相机端口绑定、图像融合和 USB 接头空间变成必须解决的工程任务。

视觉链路由采图、HSV 分割、形态学去噪、轮廓搜索和目标框组成。HSV 阈值编辑器使团队能观察颜色范围的变化；findContours 找到候选区域，boundingRect 提供目标框，再用已经标定的透视关系把图像位置转换为相对地面位置。相机支架变化会影响这一关系，因此标定文件与机械安装必须一起维护。

四摄方案还需要处理边缘畸变、画面位置和观测顺序。日志记录了裁剪、平移与按方向轮询融合，而不是把四张图片简单拼成一张全景。各方向都必须能输出一致的坐标，否则同一球跨相机时就会跳变，主程序也难以判断下一步应该怎样运动。

供电是原型能否运行的另一道门槛。普通接线方式无法可靠支撑树莓派负载，系统异常并不一定来自 Python 程序。团队把稳定的 5V 高电流供电、启动环境和服务配置一起整理，避免算法开发建立在随时可能掉电的计算板上。

科技节遥控原型先通过 HTTP 发送摇杆变化，再由后端通过 UART 发给下位机。日志记录其延迟达到数秒。改用保持长连接的 WebSocket 后，交互显著改善；它也成为检查运动方向和轮组响应的工具。这里的结论来自当时原型的实现，不能概括成所有 HTTP 系统都必然有数秒延迟。

结构验证反复出现传感器之间的冲突。LiDAR 装得过高，可能看不到希望检测的目标；倒挂尝试又被摄像头线束遮挡，形成扫描阴影。团队回到摄像头下置、LiDAR 上置，并使用视觉信息补足前方盲区。树莓派散热、屏幕接头、铜柱高度和前摄视野也在实物装配后逐项修正。

盘球机构则经历小型电机、齿轮传动和同轴轮胎结构的试验。某一版能够抓球，却因竖直占地影响其他部件而被放弃；后续同轴结构改善了滚轮一边高一边低的问题。它说明软件看到球之后，机械能否在相同高度稳定接触球仍然是独立验收项。

调试：让光线、坐标和运动使用同一套约定

旧追球方法直接用球的图像横纵坐标计算方向，近处看起来可用，远处却容易偏。日志用一个直观例子解释了原因：近处二十厘米的移动可以带来明显的像素变化，远处同样的距离只对应少量像素。摄像头的透视关系，使像素距离不能直接充当地面距离。

最初原型采用卷尺采样和函数拟合，按不同距离记录球的纵坐标。这能修正一部分纵向误差，却不能同时覆盖横向，也会因摄像头高度、角度改变而重做标定。随后团队改用矩形控制点求透视变换。在没有 Numpy 的 OpenMV 环境中，线性方程组和高斯消元承担了矩阵求解，代码的价值在于把相机安装参数变成可重新测定的映射关系。

识别墙地分界线时，只找黑色色块下边界或绿色色块上边界会受到曝光和白平衡影响；直接运行 Canny 又会找出很多不属于场地边界的边缘。团队保留线段检测，但在候选线段上下增加检查点：上方应为黑色墙面，下方应为绿色地面。只对少量检查点做 RGB 到 HSV 转换，避免全图转换占满有限算力。

曝光方案选择微欠曝，让橙色球与黄色球门更容易分开，也降低球面反光造成的颜色混淆。按钮负责快速增减曝光时间，另一项实验则扫描中心点亮度并向目标值调整。与此同时，团队提出将每台机器的接口映射和参数保存在本地文件中，减少换机器时反复改程序的工作。

这条链路也解释了 Meta 为什么需要工具界面。调 HSV 阈值时，操作者要看到候选区域；改变相机角度后，要重新检查投影；遥控时，要确认运动指令与轮子实际方向一致。调试不再只是“机器人有没有动”，而是逐层观察从画面到坐标、再到轮组的转换。

延续 / 2026.01–02：从阈值检测迈向模型部署

2026 年第一期日志把实验室与赛场灯光差异列为视觉升级的直接原因。颜色阈值依赖现场环境，重新调阈值会占用比赛准备时间；团队因此采用 YOLOv8，把球、机器人和球门等目标作为类别识别。模型提供了新的识别方式，但真实效果首先取决于数据是否覆盖比赛中的光照、背景和遮挡。

橙色球使用公开数据与自采素材，机器人目标则需要补充适合本队场景的人工标注。部署先尝试地瓜派 X5 的 INT8 路线，原始推理输出仍需要置信度筛选和 NMS 等后处理。为了缩短实现周期，日志记录团队转向 Hailo 8L 的 YOLOv8s / HEF 方案，同时推进 Jetson 平台验证。这些是不同硬件路径，不应拼成同一台机器同时装有全部计算板。

最初训练并不理想。团队只标了画面中的主要目标，同类的其他球或机器人没有完整标注。训练时，未标目标可能被作为背景参与损失计算，模型因此学习到相互矛盾的监督信息。重新整理数据、补全同类目标之后，日志记录检测明显改善。这里的重要升级是训练资料的质量，而不只是更换模型文件。

硬件接口变化也影响复现。线插错位置或换一块板，都可能迫使团队重布线和修改程序。软件可配置端口系统把映射保存到本地配置，允许不同机器保留各自的接口关系。统一运动框架则把四电机控制、外设输出和偏航角读取作为适配点，让策略不必随着每种控制板协议全部重写。

第一期 2026 日志横跨 1 月至 3 月，本篇只把其中明确落在 2 月截止范围内的选型、标注与端口工作纳入 Meta 研发线。2026 年 2 月 26 日的 Software 提交 751d65a 已加入 Jetson 环境脚本和 TunaIntelligence，球与机器人检测继续通过一致的输出队列交给 Vision。它证明后端迁移已有代码落点，但不能把随后 3 月的多进程吞吐与电气整改提前写成 Meta 的最终装机结果。

归档结果 / 截至 2026.02：留下能继续迭代的底座

Meta 的最终价值不由某一个最高帧率定义。OpenMV 的墙地分界线试验、MaixCam 的任务限帧、树莓派四摄的集中处理，分别回答不同问题：识别怎么做、有限资源怎么分配、更多传感器怎么协作。历史机型档案保留树莓派 5 与 STM32F103 的身份，研发报道则解释这些选择如何形成。

这一阶段留下四个可继承的约定：目标位置要有明确坐标系；相机编号与标定必须对应实物；端口和参数跟随每台机器保存；一次性准备与持续控制要分开。2026 年 2 月的模型后端工作在这套底座上继续展开，为 Terminus 的电控、算力和结构升级提供了共同起点。