基于ROS 2 Jazzy的端到端机械臂抓取系统实战全记录

简介：机器人操作系统（ROS）作为机器人开发的核心中间件，为复杂系统的集成提供了标准化通信与工具链支持。在机械臂抓取任务中，传统方案依赖多模块串联，误差累积与泛化能力不足成为工程痛点。端到端学习理念通过将感知与决策融合，直接学习从观测到动作的映射，但纯端到端在物理约束下落地困难。当前主流实践采用“感知端到端+规划控制闭环”的混合架构：以深度相机数据驱动抓取位姿生成，再结合MoveIt 2完成运动规划与执行。该方案兼顾模型泛化能力与安全边界，特别适用于固定工位抓取、竞赛毕设等场景。本文从ROS 2 Jazzy与Gazebo Harmonic的仿真环境搭建，到手眼标定、GraspNet推理、MoveIt 2规划及实机迁移，完整记录了一套可复现的端到端机械臂抓取系统开发流程，并梳理高频故障排查清单，为相关开发者提供切实可用的工程参考。 前阵子把一套基于ROS 2 Jazzy的端到端机械臂抓取系统完整跑通了，从Gazebo仿真到实机迁移，中间踩了不少坑，也理顺了很多之前一直模糊的环节。这个项目虽然名字叫“端到端”，但真正落地的时候你会发现，它不是“输入图像直接吐关节力矩”那么玄乎，而是感知、标定、规划、控制好几条链路紧密咬合在一起。这篇文章我按自己的实际开发顺序来写，尽量把每一步为什么这么做、怎么落地、容易在哪翻车都说清楚，给正在搞ROS 2机械臂抓取、或者准备做毕业设计/竞赛项目的朋友一份能直接参考的实操笔记。

1. 先把“端到端”这个词说清楚：项目到底在做一件什么事

1.1 传统抓取pipeline有什么问题

传统机械臂抓取系统通常是一条很长的链路：目标检测 → 目标姿态估计 → 抓取点采样 → 逆运动学求解 → 轨迹规划 → 执行。听起来每一步都很清晰，但工程上最头疼的就是误差累积。相机标定误差、手眼标定误差、检测框偏移、姿态估计不准、抓取点计算有偏差，这些误差会在链路里不断叠加，最后机械臂往往差那么一两厘米，导致抓取失败。你排查的时候根本不知道是哪一环出了问题，只能一个环节一个环节地重新标定、重新验证，非常折磨人。

而且传统方案对物体类别非常敏感。你做了一批可乐罐的抓取，换成一堆形状不规则的零件，整个视觉模块可能就要重来，泛化能力很弱。这也是为什么这几年大家都在往端到端方向走——把“看到什么”和“怎么抓”之间的手工设计环节尽量压缩，让模型直接学习从观测到动作的映射关系。

1.2 端到端到底“端”到了哪一步

需要先泼一盆冷水：完全意义上的端到端，也就是图像像素直接映射到机械臂关节力矩，目前还主要集中在实验室研究阶段，工程落地很少这么干。原因很简单：机械臂系统是强物理约束的，力矩不仅取决于目标位置，还取决于当前姿态、负载、速度，纯端到端网络很难把这些因素都塞进去，而且可解释性和安全性都很难保证。

我们在实际项目中用的“端到端”，是把任务拆成了“感知端到端 + 规划控制闭环”两段。感知端到端是指——RGB-D图像输入到一个网络里，直接输出可抓取的位姿（位置和姿态），不再单独做物体检测、点云分割、手写抓取规则这些中间步骤。规划控制闭环则是拿到抓取位姿之后，仍然交给MoveIt 2去做运动规划、避障和轨迹执行。这样既有端到端模型带来的泛化能力，又保留了规划层面的安全边界，是目前工程上最成熟、也最稳妥的落地方式。

1.3 这套系统适合谁、解决什么问题

如果你是做机械臂相关课题的学生，或者刚接触ROS 2不久、想上手一个完整项目的开发者，这套系统的参考价值会很高。它能带你把整条技术栈串起来：机器人描述文件、Gazebo仿真、手眼标定、相机驱动、深度学习推理、MoveIt 2规划、ros2_control控制，全都有实际代码和运行流程。这里我以常见的六轴机械臂（UR5或者自组3D打印臂都适用，下文以UR5为例）加上RealSense D435i深度相机为例，系统跑在Ubuntu 24.04 + ROS 2 Jazzy上，仿真环境用Gazebo Harmonic。

2. 为什么选ROS 2 Jazzy：从Humble升级过来的真实体验

2.1 Jazzy到底新在哪

如果你之前用的是ROS 2 Humble，那Jazzy Jalisco（2024年5月发布的LTS版本）值得认真考虑。它对应Ubuntu 24.04，官方支持到2029年，比Humble的支持周期更宽裕。最关键的是，Jazzy对Python 3.12的支持非常完整，很多以前需要自己编译的第三方库现在都有预编译包了，省了不少事。

另外一个很实际的变化是生态配套。MoveIt 2、Gazebo Harmonic、ros2_control、Nav2这些核心项目都同步适配了Jazzy。尤其是Gazebo，Classic Gazebo在Jazzy里已经不再推荐，官方主推Gazebo Harmonic（gz sim 8），ROS 2和它之间通过ros_gz_bridge通信。这套组合用下来，比之前Humble + Gazebo Classic的搭配要稳定不少，插件的加载方式、话题命名规律都更统一，排错成本明显降低。

提示：如果你还在Ubuntu 22.04上，不用急着升。Humble也是一条成熟路线。但如果你准备新装系统，直接上Ubuntu 24.04 + Jazzy，别用旧版本从头折腾，省下的时间非常可观。

2.2 仿真与实机共存的开发环境搭建

我在项目里坚持“先仿真、后实机”的开发方式，不是因为没有真机，而是因为仿真的迭代速度快得多。一个抓取策略在仿真里验证一次只要几十秒，在实机上可能要两三分钟，而且还要考虑碰撞、电机限位这些风险。

为了让仿真和实机尽量复用同一套代码，我把机器人描述文件、控制逻辑、视觉处理做成独立的ROS 2功能包，最下层只换一个机械臂驱动。仿真里用ros2_control的Gazebo模拟接口，实机上换成真实的UR驱动或者自组臂的串口/Modbus驱动。这样整个感知、规划、抓取决策代码一行都不用改。

环境安装上，我建议按这个顺序来，避免后续依赖打架：

# 安装ROS 2 Jazzy sudo apt install software-properties-common sudo add-apt-repository universe sudo apt update && sudo apt install ros-jazzy-desktop python3-argcomplete # 安装MoveIt 2 sudo apt install ros-jazzy-moveit # 安装Gazebo Harmonic sudo apt install ros-jazzy-ros-gzharmonic # 相机与视觉依赖 sudo apt install ros-jazzy-realsense2-camera ros-jazzy-cv-bridge ros-jazzy-pcl-ros

装完之后建议装一个非常实用的工具：ros-jazzy-easy-handeye2，手眼标定会用到，后面详细讲。

2.3 TF树和话题设计：先把“坐标”理清楚

整套系统最容易被忽视但又最基础的就是TF树。机械臂的基座坐标系、末端执行器坐标系、相机坐标系、标定板坐标系，每个坐标系之间的变换必须实时正确发布。我在项目里画了一张自己的TF树结构，顶层是world/odom，下一层是机械臂基座base_link，然后是各关节、末端tool0，相机挂在末端或者固定在工作台上方，最后是标定板aruco_marker。

这个结构直接影响后面的所有计算：抓取模型输出的位姿在相机坐标系下，必须先变换到机械臂基座坐标系，MoveIt 2才能规划执行。所以端到端系统实际上并没有减少对坐标变换的依赖，反而把精度压力集中到了“相机到机械臂”这一个变换上，这也是为什么第3部分要单独讲手眼标定。

3. 手眼标定与坐标变换：端到端系统里最容易翻车的环节

3.1 两种标定方案怎么选

手眼标定其实就是求解相机坐标系和机械臂坐标系之间的相对位姿关系。根据相机装在哪，分成两种：

• Eye-in-Hand：相机装在机械臂末端，跟着机械臂一起动。标定结果是相机相对于末端的变换。这种方案的优点是视野灵活，机械臂靠近目标时能看得很清楚，缺点是随着关节运动，标定结果误差会被放大。
• Eye-to-Hand：相机固定在工作台外侧，不随机械臂运动。标定结果是相机相对于机械臂基座的变换。这种方案视野固定，适合流水线式的固定工位抓取，标定一次就不用再管了。

我在项目里先用Eye-to-Hand，因为抓取工位是固定的，相机装在一个三脚架上俯视抓取区域，结构简单、标定结果稳定。如果你做的是移动机械臂或者需要在抓取过程中持续追踪目标，那就得用Eye-in-Hand。两种方案在easy_handeye2里都支持，它会自动控制机械臂运动到多个位姿采样标定板图像，然后求解变换矩阵。

3.2 easy_handeye2标定实战记录

标定的具体操作流程我记录一下，方便你照着走。前提是相机能正常发布图像和TF，机械臂能通过MoveIt 2控制到指定姿态。

第一步，打印一张Aruco标定板，最好是公司实验室的标准板，如果是自己打印，注意不要折皱，贴在硬纸板上。

第二步，启动标定程序。我用的是eye-to-hand模式：

ros2 launch easy_handeye2 handeye_calibration.launch.py \ robot_type:=ur \ eye_on_hand:=false \ marker_size:=0.1 \ robot_move_type:=plan

第三步，在RViz或者标定GUI里点击“Plan”让机械臂运动到不同位置，每个位置都确保标定板完整出现在相机视野里。尽量让机械臂的姿态差异大一些，平铺、俯视、斜视、高一点、低一点都来几组，采集10到15组数据。

第四步，点击“Compute”求解标定结果，然后把生成的变换矩阵写进launch文件里的静态TF。这一步一定要做，很多人标定完就忘了把结果固化下来，重启系统后变换就丢了。

3.3 TF树完整的检查方法

标定完之后，强烈建议先做一个快速验证：用tf2_echo检查各坐标系之间的变换是否连续一致，再用rviz2里的TF可视化看整套树的联动。我习惯用一个简单动作来验证标定精度——让机械臂末端移动到相机能拍到的某个固定点，然后在相机图像里确认那个点的像素坐标和通过TF反投影出来的坐标是否重叠。误差在1厘米以内基本可以接受，超过的话需要重新采样标定。

ros2 run tf2_ros tf2_echo base_link aruco_marker

如果这里输出的变换数值在不断跳动，说明TF树有问题，最常见的故障有：标定板ID没对上、相机内参没加载、静态变换发布节点重复启动。这些问题在第6部分的表格里我列了排查方向。

4. 视觉感知与端到端抓取模型：从RGB-D到抓取位姿

4.1 数据采集怎么做

感知模块用的是深度相机，RGB图像负责识别，深度图负责定位。很多初学者一上手就想直接跑预训练模型，但遇到自己的物体时效果往往很差，原因就是训练数据和目标域差距太大。所以项目里我建议自己采集一小批数据，哪怕每个物体只采50到100个样本，针对性微调之后效果都会明显提升。

采集数据的标准做法用的是ROS 2 bag，把相机话题录下来，后面离线提取图像和深度图。具体命令：

ros2 bag record -o grasp_dataset \ /camera/color/image_raw \ /camera/aligned_depth_to_color/image_raw \ /camera/color/camera_info

录制的时候把物体放在抓取区域的不同位置和角度，同一个物体尽量多摆几种姿态。还有一个小技巧是录制过程中同时记录机械臂的关节状态，这样后续做模仿学习的数据融合时能直接用。

4.2 模型选型和训练要点

感知模型的选择上，有几个方案可以按自己的计算资源来选：

• GraspNet-1Billion：经典方案，输入点云，输出若干抓取位姿及置信度。配套的抓取采样和评估模块很成熟，适合在NVIDIA显卡上做推理。
• AnyGrasp：抓取速度更快，在动态场景里有优势，对低配设备友好。
• Contact-GraspNet：在严重遮挡场景下表现不错，适合物体堆叠的情况。

我之前在项目里用的方案是：把RGB-D数据转换成点云，丢给GraspNet系列模型，拿到若干候选抓取点后，再用规则去重和筛选（比如目标工作台高度过滤、置信度阈值过滤、机器人可达性检查），最后输出一个最优抓取位姿。训练时要注意，GraspNet的标签格式是一堆抓取候选点和对应的得分，数据增强里随机旋转、平移和丢点都很关键，能显著提升泛化能力。

如果你有遥操作示教的条件，也可以考虑最近社区里热度很高的模仿学习方案（比如ACT或者LeRobot的思路），用遥操作记录机械臂的关节轨迹和图像数据，然后在“图像 + 关节状态 → 动作序列”的映射上训练一个策略。这条路如果做通了，抓取动作的流畅度会比“抓取位姿 + 规划”方式高很多，因为它学的是完整轨迹而不是单个目标点。

4.3 推理节点设计：消息流转和坐标系对齐

模型推理在项目里做成一个独立节点，订阅相机话题，输出抓取位姿。核心逻辑是：接收RGB-D图像 → 生成点云 → 模型推理 → 得到抓取位姿（在相机坐标系下） → 变换到机械臂基座坐标系 → 发布为ROS 2的PoseStamped消息。

这里有一个特别容易踩的坑：模型输出的位姿方向和机械臂末端的抓取方向定义不一致。比如模型输出的Z轴是抓取方向，但机械臂末端法兰上的Z轴可能指向另一个方向。一定要在接入MoveIt之前，验证清楚抓取坐标系和末端工具坐标系之间的旋转关系，否则机械臂会以很奇怪的姿态去抓，看起来像抽风一样。

变换的核心代码段大约是：

# 输入是模型输出的相机坐标系下的位姿 pose_camera = grasp_pose_camera # 通过TF查询相机到机械臂基座的变换 transform = tf_buffer.lookup_transform( 'base_link', camera_frame, rclpy.time.Time()) pose_base = tf2_geometry_msgs.do_transform_pose( pose_camera, transform) # 发布给MoveIt 2作为目标位姿 grasp_pose_pub.publish(pose_base)

我记得第一次跑通那个瞬间，机械臂稳稳地移动到目标上方、张开夹爪、下落抓取、抬起，一气呵成，那种成就感是写多少代码都替代不了的。

5. MoveIt 2规划与执行链路：从目标位姿到关节运动

5.1 MoveIt 2配置踩坑记录

MoveIt 2是老朋友了，但在Jazzy上配置时还是有几个细节要注意。首先是SRDF文件里必须定义好规划组（planning group），比如手臂是一个组、夹爪是另一个组，否则后面做抓取规划时MoveIt不知道你要动哪几个关节。

其次，碰撞矩阵不要太严格也不用太宽松。太严格会导致机械臂稍微离物体近一点就报“No valid trajectory found”，太宽松又容易真的撞到东西。我常用的做法是：工作台平面作为无限碰撞物体加入场景，目标物体只在最后几厘米的接近阶段加入场景，抓取成功后立刻移除。这样既保证安全又不至于频繁规划失败。

MoveIt 2默认的规划器是OMPL里的RRTConnect，大多数情况下够用。但在狭窄或复杂环境下，TRAC-IK求逆解的成功率通常比KDL高很多，建议把MoveIt配置里的IK插件改成TRAC-IK，能省掉很多“逆解失败”的烦恼。

5.2 从抓取位姿到关节轨迹

这里有一个设计细节值得单独说说：从目标抓取位姿到最终轨迹，我一般拆成三段——预抓取位姿、抓取位姿、抬起位姿。

• 预抓取位姿：目标位姿沿Z方向后退大约10到15厘米，机械臂先快速运动到这里，避免直接冲向目标物体。
• 抓取位姿：从预抓取位姿直线接近目标，速度放慢，这一步往往需要开启笛卡尔空间路径规划，保证末端走直线。
• 抬起位姿：夹爪闭合后，沿Z方向上升10厘米左右，再过渡到下一个动作。

这样拆分的好处是，避障和精确接近被分到了两个不同的规划阶段，复杂度大大降低，而且机械臂动作看起来更自然。MoveIt 2里实现末端直线运动，用的是compute_cartesian_path，把步长设小一点（0.01米左右），并把跳点阈值控制住，轨迹就不会发生奇怪的大跳跃。

5.3 从仿真迁移到实机的关键点

仿真里跑通的代码，迁移到实机时大概率会暴露三个问题。第一是控制周期。仿真里关节响应几乎是瞬间的，但实机的电机、驱动器有响应延迟，尤其是自组臂，PID参数没调好时抓取动作会抖。第二是力觉和碰撞，Gazebo里碰撞检测是理想的，实机上夹爪闭合力、末端接触力都需要额外处理，至少要加一个过流保护或者力传感器反馈。第三是标定数据，仿真里用Gazebo发布TF，实机上要换成真实的相机内参和手眼矩阵，这一步最容易漏。

我的经验是迁移前先在实机上单独验证三个子模块：机械臂能不能按MoveIt规划平滑运动、相机话题能不能稳定发布对齐的深度图、手眼标定矩阵是否可靠。三个模块各自验证通过后，再合并整个抓取流程，排查起来会轻松很多。

6. 常见问题速查与我的排错笔记

6.1 先看这张表

项目运行过程中遇到的高频问题，我整理成了表格，照着排查效率会高很多。

6.2 TF与标定相关排错记录

手眼标定排在“翻车率第一”一点不夸张。我印象最深的一次，标定结果看起来合理，但机械臂实际就是抓偏了大约两厘米。后来反复检查发现，标定的时候用的标定板尺寸是0.1米，但Aruco检测节点里默认配置的marker size写成0.08米，尺寸错了导致整个尺度估计不准，变换矩阵当然也跟着错。这个问题藏在配置里，从标定过程的画面根本看不出来。

还有一个经验是，标定完成后不要马上删掉标定板的launch文件。前期调试阶段，把标定板和相机之间的变换单独发布出来，用来交叉检查手眼矩阵是否一致，非常有用。等系统稳定运行一周后，再决定要不要从启动项里移除。

6.3 控制与规划相关排错记录

MoveIt 2在Jazzy上规划失败时报错信息有时候不太明确，遇到“Failed to find IK solution”时，我第一个排查的永远是当前目标位姿是否在机械臂的工作空间内。RViz里拖动末端目标点能到达的位置，程序里算出来的位姿不一定能达到，因为模型参考点可能不同。再一个经常被忽视的是关节速度限制，MoveIt里默认的速度缩放因子在实机上可能不够，会导致执行时轨迹跟踪误差累积，末端最后偏离目标点。这个问题的典型表现是仿真里一切正常、实机上每次都差一点，这时候把执行速度降到0.5倍甚至0.3倍重新试，往往就好了。

7. 还能往哪走：从固定抓取到开放世界的几个扩展方向

7.1 物理-数据双驱动的神经同化：最近很热的思路

最近社区里“物理-数据双驱动的端到端神经同化方法”热度很高，思路是把物理模型（机械臂运动学、动力学模型）和数据驱动的神经网络结合起来，用物理约束去约束神经网络的输出，同时用真实数据持续校正物理模型的误差。放到机械臂抓取上，这种思路可以缓解“仿真到实机”的迁移问题——仿真里学到的策略，通过物理模型和数据共同“同化”到真实机械臂上，比纯迁移学习更稳。我目前也在关注这个方向，后续如果跑通了，应该会单独写一篇。

7.2 模仿学习与遥操作数据复用

如果你决心往具身智能方向走，遥操作采集数据 + 模仿学习是最值得投入的方向。LeRobot这类开源项目已经提供了很完整的采集和训练工具链，机械臂的3D打印文件、数据采集SDK、模型训练代码都有，配合你手里的ROS 2系统，完全可以在自己搭建的机械臂上复现一套“看图像生成动作”的策略。这样一路做下来，不只抓取，叠杯子、开关门这类动作也能泛化出来。

7.3 硬件低成本化的个人建议

预算有限的话，3D打印机械臂加普通步进电机是一个能接受的入门方案，很多开源项目都有现成的机械结构图纸。但是要做好心理准备：结构刚性、电机精度、夹爪设计的每一点妥协，最终都会反馈到抓取成功率上。我的建议是，如果你目标是快速跑通整套软件流程，优先选择一款精度可靠的成品机械臂；如果目标是锻炼结构设计和底层控制能力，再考虑自组方案。两种路线我都试过，自组方案学到的东西确实多，但也确实耗时间。

最后再分享一个小技巧：整个抓取流程跑通之后，不要只测固定位置的抓取，试着在抓取区域内随机摆放物体、调换不同形状的物品、改变光照条件，把系统往真实环境里“逼一逼”，你会很快发现模型的泛化边界到底在哪。根据我个人经验，一个抓取系统的可靠，不是靠调好一组参数，而是靠你不停地把不确定的东西暴露出来、再一个个解决掉。希望这篇笔记能帮你在自己的项目里少走几个弯路。

本文还有配套的精品资源，点击获取