最近在指导几位同学完成采摘机器人相关的毕业设计，发现大家普遍在从理论到实践的转化过程中遇到不少共性问题。比如算法在电脑上跑得好好的，一上实机就各种延迟、丢帧；机械臂的运动规划和视觉感知像是两个独立的系统，难以协同；还有系统集成后调试困难，牵一发而动全身。结合这些实际痛点，我梳理了一套基于ROS 2和STM32的全栈实现方案，希望能为正在或即将进行类似毕设的同学提供一个清晰、可复现的参考路径。
1. 毕业设计常见痛点深度剖析
在开始技术选型之前，我们先明确要解决哪些核心问题。很多同学的毕设停留在仿真或单个模块演示阶段，难以形成完整的闭环系统，主要痛点集中在以下几个方面：
- 算法与执行器严重脱节：这是最常见的问题。同学们往往在Jupyter Notebook或OpenCV的窗口中完成了漂亮的果实识别，识别框画得精准，但识别结果如何转换成机械臂末端执行器的空间坐标？这个坐标转换涉及相机标定、手眼标定、坐标系变换等一系列步骤，任何一个环节出错都会导致'看得见但抓不着'。更复杂的是，视觉算法输出的频率（如10Hz）与底层电机控制频率（可能高达100Hz）不匹配，如果没有良好的中间层进行解耦和缓存，就会导致控制指令混乱。
- 系统缺乏实时性保障：采摘动作对时效性有一定要求。果实识别、路径规划、运动控制整个链路如果延迟过高，当机械臂运动到目标位置时，果实可能因风吹或机器人自身移动而偏离了原位。许多同学用纯Python或ROS 1的默认通信机制，在多节点、高频率数据流下，延迟和抖动会变得不可预测，严重影响抓取成功率。
- 模块集成混乱，调试困难：视觉、控制、机械、上位机等多个模块由不同代码、不同语言（Python/C++）编写，集成时接口不统一，通信协议随意定义。一旦出现问题，比如机械臂不动了，很难快速定位是视觉没发数据，还是通信丢包，或是底层驱动器故障。缺乏系统性的日志记录和状态监控，使得调试过程如同'黑盒'摸索。
- 对真实环境干扰准备不足：实验室环境光照均匀，背景干净。但实际应用中，光照变化、枝叶遮挡、果实颜色与背景相似、相机抖动等问题会极大影响识别效果。很多算法在干净数据集上表现优异，但未考虑这些鲁棒性因素，导致演示时'见光死'。
2. 核心技术选型对比与决策
针对上述痛点，我们的技术选型需要围绕实时性、模块化、鲁棒性和开发效率进行权衡。
- 机器人中间件：ROS 1 vs ROS 2
- ROS 1：成熟，社区资源丰富，是很多教学和研究的首选。但其核心通信机制基于TCPROS/UDPROS，实时性较差，且主节点（Master）存在单点故障风险。
- ROS 2：采用DDS（数据分发服务）作为底层通信架构，天生支持实时系统和分布式部署，通信质量（QoS）可配置，能更好地满足我们对延迟和可靠性的要求。虽然学习曲线稍陡，但对于一个追求性能的毕设项目，ROS 2是更面向未来的选择。我们选用ROS 2 Humble版本，其稳定性和对嵌入式平台的支持都较好。
- 视觉感知：传统OpenCV方法 vs 深度学习YOLO
- 传统方法（如颜色分割、轮廓检测）：在环境可控、果实特征明显（如红色番茄在绿色背景中）时，速度快、无需训练。但鲁棒性差，极易受光照和遮挡影响。
- 深度学习（YOLOv8）：YOLOv8在精度和速度上取得了很好的平衡，其n/s/m/l不同尺度的模型为我们在算力有限的嵌入式设备上部署提供了灵活性。通过收集和标注自己场景下的数据（哪怕只有几百张）进行微调，模型能学会抵抗一定的光照变化和遮挡，泛化能力远强于传统方法。我们选择YOLOv8s模型，在Jetson Nano或树莓派+加速棒上可以实现接近实时的推理速度。
- 下位机控制器：Arduino vs STM32
- Arduino：开发简单，生态丰富，适合快速原型验证单个功能（如驱动一个舵机）。但其处理能力有限，难以复杂运算；缺乏真正的实时操作系统支持，多任务管理靠
loop轮询，时序精度不高。 - STM32：基于ARM Cortex-M内核，主频高，外设丰富。配合实时操作系统，可以轻松创建多个具有不同优先级的任务，确保电机控制、编码器反馈、通信等关键任务的实时性。例如，可以将PID控制循环放在一个高优先级定时器中断或任务中，保证其严格周期执行。我们选择，性能足够且性价比高。
- Arduino：开发简单，生态丰富，适合快速原型验证单个功能（如驱动一个舵机）。但其处理能力有限，难以复杂运算；缺乏真正的实时操作系统支持，多任务管理靠
