简介基于ROS2的UR5机器人抓取仿真项目面向机器人专业学生与ROS2开发者适用于毕业设计、课程设计或期末大作业。资源共包含433个文件压缩包大小仅1.3MB主要涉及cmake构建脚本、yaml参数配置、xacro机器人描述、C/Python控制节点、Shell启动脚本等目录结构清晰便于按模块查阅。目前已有231人学习下载。项目完整覆盖ROS2环境搭建、UR5的URDF模型导入、Gazebo运动学与动力学仿真以及抓取任务中的视觉识别、路径规划与精确抓取控制逻辑并针对物体识别失败、路径规划错误、抓取滑落等异常情况提供处理思路。配套的README、gitignore和构建文件可帮助快速理解项目结构、复现仿真环境是一份可直接参考的完整工程实践资料。1. 一个 .zip 承载的其实是一整条抓取链路先搞清目录结构再动手拿到“基于ROS2的UR5机器人抓取仿真.zip”最容易犯的错就是把解压当成功启动。这个压缩包通常不只是一个URDF模型而是一整套工程Gazebo的world文件、MoveIt配置、启动脚本以及感知与抓取示例。它要解决的是“在仿真里让UR5从识别物体到位姿计算、无碰撞规划、末端执行形成闭环”。适合刚搭好ROS2准备做机械臂抓取的开发者也适合把仿真结果迁移到真实UR5之前做方案验证的人。如果你已经会用MoveIt可以直接跳到坐标系列表后面几个坑才是决定仿真能不能稳定跑出结果的关键。2. 先让UR5在ROS2里动起来版本匹配、安装与首个launch2.1 选ROS2版本与仿真器为什么常见组合是Humble Gazebo做UR5抓取仿真第一步不是写代码而是选版本。我在多台机器上试过Foxy、Galactic、Humble最终稳定停在Ubuntu 22.04 ROS2 Humble Gazebo Classic的组合。原因很简单UR官方驱动和MoveIt2的humble分支维护最活跃网上绝大多数基于ROS2的UR5抓取仿真项目也是同一套。很多ROS2安装教程只教你apt装desktop后面装Gazebo和MoveIt时才发现依赖冲突所以这里我给一套一次装齐的组合。Humble是LTS版本支持到2027年避免在非LTS版本上做到一半被依赖项拖垮。Gazebo Classic也就是Gazebo 11和ROS2之间的桥接包gazebo_ros在Humble上有现成二进制不需要从源码编译。新版Ignition Gazebo物理性能更好但UR5相关教程和world文件大多是旧格式迁移成本高。如果你拿到的zip里world文件是.sdf格式用Gazebo Classic最稳。# 确认操作系统版本Ubuntu 22.04是Humble最省心的底座 cat /etc/os-release # 建议一次性装齐桌面版、Gazebo桥接和MoveIt sudo apt update sudo apt install ros-humble-desktop ros-humble-gazebo-ros ros-humble-gazebo-plugins sudo apt install ros-humble-moveit ros-humble-moveit-ros-move-group ros-humble-moveit-setup-assistantgazebo-plugins提供libgazebo_ros_*系列插件没有它你后面spawn实体和控制手爪都会缺文件。moveit-setup-assistant是图形化配置工具如果只是跑别人配置好的包可能用不到但自己改模型时一定会用。装完后先确认环境echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc ros2 --version如果输出ros2: command not found多半是conda或老版本ROS污染了环境变量。这时不要急着重装先检查~/.bashrc里是否被插入了奇怪路径。仿真过程中如果出现rviz2掉线、tf断续也可以把DDS实现固定为Fast DDSexport RMW_IMPLEMENTATIONrmw_fastrtps_cpp这一步在后续同时跑Gazebo、MoveIt和感知节点时尤其值得做能避免很多“明明都启动成功却收不到数据”的玄学问题。2.2 拉取UR官方模型与驱动包先跑通“能看到UR5”多数zip里的UR5模型取自Universal Robots官方驱动仓库。最好不要直接从其他项目里拷一个urdf因为URDF里的摩擦参数、传动参数决定后面物理仿真真实性。我一般从官方humble分支拉一份再根据自己项目改。mkdir -p ~/ur_ws/src cd ~/ur_ws/src git clone -b humble https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver.git cd ~/ur_ws sudo rosdep install --from-paths src --ignore-src -r -y colcon build --symlink-install source install/setup.bash--symlink-install让代码以软链方式放进install目录后续改urdf和launch不用重新编译直接生效。rosdep install如果报错说明系统缺Python依赖安装python3-rosdep后重新执行。如果你在clone时发现网络慢可以用镜像站但注意不要混用不同分支的代码我曾经混过iron分支到humble环境里CMake直接崩。构建完成后跑一个最小显示ros2 launch ur_description view_ur5.launch.py如果看到rviz2窗口里出现UR5说明模型和robot_state_publisher正常。注意这个launch默认发布全零关节状态机械臂会处于竖直姿态。看到模型先别急着高兴下一步验证tf树。2.3 验证launchrviz2里看到UR5不算完还要检查tf树看得到模型只证明urdf解析成功真正决定抓取精度的是tf树。UR5有7个关节从base_link到tool0的tf链必须完整。直接命令行验证ros2 run tf2_ros tf2_echo base_link tool0如果每秒输出一段变换说明链路通。接着用工具生成tf树图方便肉眼检查ros2 run tf2_tools view_frames.py会生成frames.pdf。打开后检查所有link必须是连续父子关系不能有断点也不能有两个link同时挂在同一个父节点下。曾经遇到一个工程在wrist_2_link和wrist_3_link之间加了多余frame导致MoveIt规划时末端位置正常但执行时手腕反向转排查了很久。再检查关节话题ros2 topic info /joint_states --verbose如果看到两个publisher这就是后面“关节乱跳”的根源。在纯rviz2阶段通常只有一个joint_state_publisher等Gazebo启动后会变成两个到时候要记得处理。现在知道这个概念就行后面避坑章节细说。3. 把UR5装进仿真世界URDF、坐标系与MoveIt配置3.1 UR5的坐标系链与tf树抓取前必须搞清的几个关键frame许多人在rviz2里选中物体以为那位姿就是末端要去的点。实际上抓取仿真中机械臂末端是tool0而物体目标位姿需要换算到base_link下。UR5的坐标系链如下表frame含义抓取中作用base_link机械臂安装基准所有规划目标默认参考系shoulder_link腰关节第一个旋转自由度upper_arm_link大臂决定小臂位置forearm_link小臂决定腕部位置wrist_1/2/3_link腕部三轴调整末端姿态tool0末端工具安装面抓取中心通常从这里再偏移使用标准UR5的urdf时tool0相对wrist_3_link有一个固定偏移。不同型号不一样UR5大约0.0811mUR5e会略有不同。如果zip里带的是自建模型一定要打开urdf看这段!-- 典型UR5 tool0固定关节数值以你模型为准 -- joint nametool0_joint typefixed parent linkwrist_3_link/ child linktool0/ origin xyz0 0 0.0811/ /joint这个偏移直接影响抓取点计算。如果你的手爪模型是直接装在tool0下面那MoveIt规划的目标位姿实际上算到了tool0而不是夹爪中心。很多抓取失败都源自这里。另外要注意base_link不在机械臂底座底面而是在安装法兰中心。如果你在Gazebo里调整了机械臂位置或角度base_link会跟着变所有感知结果都要明确frame不能默认世界原点。3.2 用MoveIt配置UR5从URDF到可规划的机械臂MoveIt负责碰撞检测与路径规划。很多项目zip里直接带了moveit_config目录但如果你想自己搭推荐用moveit_setup_assistant生成而不是手工写yaml。这个工具是图形界面的一步步点下来不容易漏。ros2 run moveit_setup_assistant moveit_setup_assistant加载你改好的UR5 urdf或xacro然后生成SRDF。关键配置点有三个。第一个是规划组我一般叫arm从base_link到wrist_3_link这组负责末端位姿规划。第二个是规划组gripper从tool0下挂的gripper_link用于手爪开合。第三个是末端执行器选择gripperparent link填tool0。运动学求解器选KDL其他求解器在仿真里没有明显优势KDL对UR5的6轴模型成熟稳定。如果你不想自己生成直接用官方ur_moveit_config包也能跑ros2 launch ur_moveit_config ur5_moveit_planning_execution.launch.py这个launch会启动move_group、规划场景和rviz2。rviz2里勾选MotionPlanning插件后可以拖拽目标点位。我强烈建议第一次使用这种方式验证而不是直接写脚本因为图形界面能让你直观看到规划路径是否合理。3.3 抓取位姿计算物体坐标系到机械臂坐标系的转换假设感知节点拿到了物体在object_frame下的位姿最终要给MoveIt下发base_link下的目标。这里要用tf。这是一个示例节点import rclpy from rclpy.node import Node from tf2_ros import Buffer, TransformListener from rclpy.duration import Duration class TfLookup(Node): def __init__(self): super().__init__(tf_lookup) self.buf Buffer() self.listener TransformListener(self.buf, self) def get_object_in_base(self, object_frameobject_frame): try: # lookup_transform(目标frame, 源frame, 时间) t self.buf.lookup_transform(base_link, object_frame, rclpy.time.Time(), Duration(seconds1.0)) return t.transform.translation, t.transform.rotation except Exception as e: self.get_logger().warn(fTF lookup failed: {e}) return None rclpy.init() node TfLookup() # 真实节点中拿到位姿后发布成PoseStamped供MoveIt使用 print(node.get_object_in_base())这段代码假设物体坐标系已经发布如果感知输出在camera_link下把源frame改成camera_link。注意lookup_transform的时间参数用rclpy.time.Time()表示取最新数据不要用当前时间戳否则tf2会经常报Lookup would time out。第一次调用可能需要等一两秒因为tf缓冲是异步填充的。拿到物体位姿后不要在代码里直接加偏移改成抓取点。更稳的做法是定义一个预抓取点比物体中心高出手爪宽度加一点点安全距离。比如盒子高度5cm夹爪宽度6cm那么末端应该在盒子中心上方至少8cm处。这个偏移写在MoveIt目标里而不是改视觉结果。4. 抓取流程落地感知、规划、执行的最小实现4.1 仿真里的感知直接读取Gazebo model_states别一上来就卷积网络仿真抓取的重点不是视觉算法而是从位姿到规划的闭环。很多项目为了看起来高级用YOLO识别物体结果机械臂抓取成功率反而不高因为目标检测框到3D位姿本身就有误差。仿真里最简单可靠的感知是直接订阅/gazebo/model_states它给你每个模型的真实位姿。这相当于给你一个免费的地面真值。import rclpy from rclpy.node import Node from gazebo_msgs.msg import ModelStates class ModelPoseReader(Node): def __init__(self): super().__init__(model_pose_reader) self.create_subscription(ModelStates, /gazebo/model_states, self.cb, 10) def cb(self, msg): # 在模型列表里找到目标物体例如名为coke_can if coke_can not in msg.name: return idx msg.name.index(coke_can) pose msg.pose[idx] self.get_logger().info( fposition{pose.position.x:.3f},{pose.position.y:.3f},{pose.position.z:.3f} ) # 将pose发布成PoseStamped供下游MoveIt使用 rclpy.init() rclpy.spin(ModelPoseReader())注意msg.name、msg.pose、msg.twist是平行数组用index对应。如果你spawn物体时用了-entity target_box那msg.name里就要判断target_box。这个节点只读取不发布TF所以后续必须把位姿从world转换到base_link。如果机械臂的base_link和world原点不重合不能直接把model_states的position当作MoveIt的goal这是新手最容易踩的坑。4.2 启动仿真MoveIt照着这个流程先跑通一次手动抓取完成感知节点后先不要写自动化脚本先把整个系统跑起来用rviz2手动规划一次。启动顺序很重要一般在三个终端里# 终端1启动带UR5和物体的Gazebo场景 ros2 launch ur_gazebo ur5_with_gripper.launch.py# 终端2启动MoveIt规划 ros2 launch ur_moveit_config ur5_moveit_planning_execution.launch.py# 终端3向Gazebo里插入一个物体例如盒子 ros2 run gazebo_ros spawn_entity.py -entity target_box \ -file /path/to/box.sdf -x 0.5 -y 0.1 -z 0.8在不同工程中launch包名可能不同有的叫ur_gazebo有的叫ur5_gazebo。核心是确保MoveIt和Gazebo共用同一个/robot_description。在rviz2里展开MotionPlanning面板点击Plan看到路径点击Execute机械臂应平滑移动。手动验证时有个技巧先把目标姿态调整为垂直向下再拖拽位置。很多项目推荐用默认姿态规划结果手爪横着撞到物体或桌面。拖拽目标时注意看rviz2里的碰撞状态如果目标点周围显示红色说明会导致碰撞需要抬高。这一步跑通后至少说明MoveIt配置、Gazebo驱动、tf链三方面没有问题。4.3 自动化的下一步把位姿喂给MoveIt并控制手爪闭合手动跑通后才开始写自动抓取节点。自动化要解决两件事一是把感知位姿变成MoveIt的goal二是抓到手后让手爪闭合。MoveIt2各版本的Python API差异比较大这里给一个结构正确的示例具体字段以你安装版本的官方demo为准from moveit_msgs.action import MoveGroup from moveit_msgs.msg import Constraints, PositionConstraint from moveit_msgs.msg import MotionPlanRequest # 构造goal核心是group_name和goal_constraints goal MoveGroup.Goal() goal.request.group_name arm constraint Constraints() pc PositionConstraint() pc.link_name tool0 pc.target_point_offset.x 0.0 pc.target_point_offset.y 0.0 pc.target_point_offset.z 0.05 # 比物体高5cm预抓取 # 约束区域设置成1cm立方体降低逆解求解难度 pc.constraint_region.primitives[0].type 1 # 1BOX pc.constraint_region.primitives[0].dimensions [0.01, 0.01, 0.01] constraint.position_constraints.append(pc) goal.request.goal_constraints.append(constraint)这个代码段是示意实际还会加上姿态约束和start_state。位置约束里的constraint_region是最容易写错的地方如果规划器报No planning solution先把维度放宽到2cm试试。更常用的做法是只给PositionConstraint姿态约束省略因为UR5腕部自由度多很多角度都能到达。当你发现规划时间过长可以限定goal.request.max_planning_time为5秒并打开goal.request.planner_id。手爪控制要看你的仿真手爪是什么驱动。如果是gazebo_ros的JointTrajectoryController可以发话题ros2 topic pub -1 /gripper_controller/joint_trajectory trajectory_msgs/msg/JointTrajectory \ {joint_names: [finger_joint], points: [{positions: [0.05], velocities: [0.1]}]}这里的0.05表示手爪张开到一半。如果手爪是effort驱动就改发JointEffort消息。不要死记先看手爪urdf里定义了哪种transmission。如果手爪没有动用rqt_graph看话题是否连通并检查controller是否加载。仿真与真实抓取还有一个显著差异model_states给的位姿是理想值真实相机有噪声。所以仿真跑通后我建议在目标位姿上加±5mm的随机扰动再抓看你的方案能不能接受。这能提前暴露手爪对齐精度的漏洞。5. 避坑UR5仿真抓取里我踩过的5个坑5.1 关节乱跳两个joint_states发布源在打架现象Gazebo启动后rviz2里的UR5模型不断抖动关节角度在异常值之间跳变。原因ur_description的view_ur5.launch.py里默认启动了joint_state_publisher而Gazebo也会发布/joint_states。两个发布者同时存在robot_state_publisher收到两个时间戳相同的消息tf错乱。解决在Gazebo仿真中只让Gazebo的/joint_states作为唯一来源。在启动脚本里禁用joint_state_publisher或者在launch文件中删除那一段。检查方法ros2 topic info /joint_states --verbose如果看到两个Publisher按CtrlC关闭其中一个。我一般会写一个只启动Gazebo和MoveIt的launch把rviz2的joint_state_publisher完全剥离这样环境干净排查问题也快。5.2 找不到运动学解MoveIt缺少KDL插件现象在rviz2里点Plan提示Failed to load kinematics plugin或者No kinematics solver。原因用moveit_setup_assistant生成配置时如果没有选运动学求解器或者系统没装KDL插件move_group就不知道如何求解逆解。UR5虽然是6轴逆解本身有解析解但缺少插件就是不工作。解决安装插件并在moveit_config的kinematics.yaml里指定sudo apt install ros-humble-kdl-kinematics-plugin然后打开kinematics.yaml确认有arm: kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin kinematics_solver_search_resolution: 0.005 kinematics_solver_timeout: 0.05改完重开launch。如果仍报错看move_group启动日志里加载的插件路径常见原因是多个moveit_config包并存ros2 launch加载了错误的包路径。5.3 抓取位置总差一截tool0与抓取中心没对齐现象机械臂按MoveIt规划走到目标点但手爪中心离物体表面总是差2cm。原因MoveIt规划的链路末端是tool0不是手爪的抓取点。tool0在wrist_3_link后面如果你的手爪模型挂载在tool0下并且抓取中心在gripper_link那么目标位姿应相对gripper_link。很多项目直接在MoveIt里把end_effector设成tool0手爪实际中心却被忽略。解决在MoveIt配置的end_effector里把parent_link设成tool0但goal的link_name要用gripper_link。如果模型里没有gripper_link就回头查urdf。更简单的办法在目标位姿的z上加一个固定偏移这个偏移就是tool0到夹爪中心的距离通常0.05到0.10m。每次改动后记录在参数文件中别写死在代码里因为换一个手爪模型就要改。5.4 物体被碰飞物理参数与碰撞检测不一致现象机械臂还没碰到物体物体就弹飞或陷入桌面。原因MoveIt的碰撞检测用的是几何形状Gazebo物理引擎用的是惯性、摩擦和接触系数。如果SDF里没有设置摩擦系数默认Mu为0物体如冰一样滑如果碰撞网格比视觉模型小机械臂会穿模。解决在物体的SDF模型里给collision和surface添加摩擦surface friction odemu1.0/mumu21.0/mu2/ode /friction contact odekp1000000.0/kpkd100.0/kd/ode /contact /surface同时确保MoveIt里的碰撞物体尺寸比视觉模型大1到2mm给抓取留安全间隙。如果物体还在跳把Gazebo步长从1ms调小到0.5ms但会增加CPU占用我用过一段时间后来换了更好的摩擦参数才解决。5.5 规划完不动controller_manager没有接管轨迹现象MoveIt规划成功Execute后move_group显示Done但Gazebo里的UR5纹丝不动。原因MoveIt把轨迹发给了/follow_joint_trajectory但Gazebo侧没有加载对应的controller或者controller名字对不上。也可能是joint_trajectory_controller没有导入到运行状态。解决检查controller_manager状态ros2 control list_controllers看有没有joint_trajectory_controller。如果显示未配置在launch里加载controller yaml。常见错是包路径写错MoveIt期望的action名是/follow_joint_trajectory而你的controller发布为/joint_trajectory_controller。改yaml或者给MoveIt传参数二选一对齐。在Gazebo仿真里还要确保use_sim_time为true否则轨迹时间戳与实际时间对不上MoveIt以为执行完成实际Gazebo根本没有收到有效轨迹。6. 进阶验证用重复抓取实验把仿真结果调成可信结果手动抓取能成功一次并不说明方案可用。我在项目里至少做30次重复抓取并记录成功率、平均规划时间、碰撞次数。这里有个简单脚本#!/bin/bash for i in $(seq 1 30); do # 随机生成物体的x在0.4-0.6y在-0.2-0.2 ros2 run gazebo_ros spawn_entity.py -urdf -file box.urdf \ -entity box_$i -x 0.$((RANDOM%34)) -y 0.$((RANDOM%5-2)) -z 0.05 sleep 2 # 调用你的抓取节点 ros2 run pick_demo pick_node sleep 3 done这个脚本只是骨架真正的验证要把每次抓取成功与否记录下来并回放bag。我一般会同时记录/joint_states和/gazebo/model_states方便失败时定位是规划问题还是控制问题。回放时用ros2 bag play -r 2.0加速比重新跑一次仿真快很多。更值得做的验证是预抓取点策略。我第一次写自动抓取时直接规划到最终抓取位姿结果手爪总是撞到物体成功率只有六成。改成两步后成功率到了95%先规划到物体上方10cm的点目标姿态固定垂直向下再规划垂直向下5cm的抓取点。第二步规划时把第一步规划的终点作为起始状态路径短且稳定。# 用上一步的末端位姿作为下一步起始减少碰撞 goal.request.start_state.is_diff True # 提示MoveIt从当前实时状态出发两段式移动在仿真里能让路径更平滑放在真实UR5上也更安全。如果你发现两步之间衔接有停顿把第一段的末端姿态和第二段起始姿态设为完全一致再在MoveIt里设置一个goal_tolerance关节角度误差放宽到0.02弧度执行会更流畅。这套流程走下来你会发现真正影响抓取仿真可信度的不是模型精度而是坐标系一致性和控制器状态。我至今还保留着每次换环境先跑一次tf2_echo、再跑一次重复实验的习惯。希望帮到你。本文还有配套的精品资源点击获取