基于ROS 2 Jazzy的端到端机械臂抓取系统实战：从选型到调试全解析

简介：机器人抓取是智能制造与仓储自动化中的关键环节，其核心挑战在于打通感知、规划与控制的全链路。以ROS 2 Jazzy为代表的长期支持版本，为这类系统提供了稳定可靠的通信与工具链基础。结合RGB-D相机与MoveIt 2运动规划，开发者可以构建从图像输入到夹爪动作的端到端闭环：先通过目标检测与点云位姿估计获取抓取点，再利用OMPL规划无碰撞轨迹，最后由ros2_control驱动执行。这一技术路线不仅提升了抓取成功率，也大幅缩短了部署周期，广泛适用于工业分拣、物流码垛等场景。围绕Jazzy环境搭建、MoveIt 2参数调优、TF坐标系校准及QoS策略配置，本文完整记录了一套可复用的机械臂抓取系统实现与调试过程，为相关工程实践提供真实参考。 折腾了大概一个多月，我这套基于ROS 2 Jazzy的端到端机械臂抓取系统终于从“能看不能动”变成了“看见就能抓”。工程整理完之后打包成了一个zip归档，方便以后直接复用。这篇文章就是把整个系统的选型逻辑、模块拆解、环境搭建、核心实现和调试过程完整记录下来，给正在捣鼓Jazzy抓取的朋友一个可以直接参考的路线图。

这套系统适合什么场景？你手头有一台六轴机械臂，配一个RGB-D相机，想让它自己看到工作台上的物体，规划出一条不撞环境的路径，然后控制夹爪准确夹起来放到目标区域。它不只是手动触发一个预设轨迹，而是从传感器数据到机械臂动作全自动闭环。如果你也想摆脱那种“按钮触发单项动作”的演示级demo，这套方案里的代码框架和踩坑记录能帮你省掉几周的试探时间。

1. 为什么是Jazzy：端到端抓取系统选型时的底层考量

很多人在选ROS 2版本时会纠结，尤其对比Humble、Iron、Rolling。我在这次项目里最终选定了Jazzy，不是因为它最新，而是因为它刚好满足端到端抓取系统的两个硬性要求：长期可维护性，以及配套工具链的成熟度。

1.1 LTS周期和依赖基线决定了你半年后要不要重写

ROS 2的发行版里，Jazzy Jalisco是2024年5月发布的LTS版本，官方支持周期到2029年。什么意思？对于机械臂系统来说，部署现场不会像开发机一样天天改环境，客户要的可能是一套三年后还能稳定运行的控制系统。选一个长期维护的版本，意味着你会持续收到安全更新和关键bug修复，而不是频繁被版本升级逼着重写代码。

对比一下：Humble是2022年的LTS，支持到2027年，已经走过了生命周期的一半；Rolling是滚动版本，适合尝鲜，但今天能编过的代码下个月可能因为某个核心库API变动就编不过了。Jazzy在这两者之间取了一个非常舒服的点：它比Humble多了两年维护期，又不像Rolling那样随时可能破坏性变更。对于端到端机械臂抓取这种“感知+规划+控制”耦合很深的项目，底层库的稳定性直接决定上层逻辑要不要跟着改，所以Jazzy是我当时的首选。

另一个实际因素是Jazzy默认绑定Ubuntu 24.04。24.04是新的LTS系统，glibc、Python、OpenCV等关键依赖都是比较新的版本，这意味着你不需要为了跑一个视觉模型去编译一堆老版本的依赖库。比如OpenCV在Ubuntu 24.04的apt源里已经是4.10，PyTorch也在这套环境里长期提供预编译包，视觉部分的集成会轻松很多。

1.2 生态同步程度比单纯的版本号更重要

选ROS 2发行版，不能只看ROS 2本身，还得看MoveIt 2、ros2_control、Gazebo、相机驱动这些周边生态是否同步支持。Jazzy发布后，MoveIt 2在同年就提供了对应的二进制包，ros2_control也把Jazzy列入了稳定的发行列表。我实际装的时候只需要一条apt命令就能装好，不需要从源码编译，这对一个复杂项目来说少了很多不确定性。

特别是MoveIt 2对Jazzy的支持，在OMPL、FCL碰撞检测库这些底层组件上都做过一轮适配，规划稳定性比Humble时代明显好一些。Gazebo跟Jazzy配合用的是Gazebo Harmonic，仿真里的摩擦力、接触响应参数可以跟真实环境保持一致，这对抓取仿真测试非常重要。如果你用老版本Gazebo Classic，在Ubuntu 24.04上可能连编译都过不了。选Jazzy，本质上是选一个已经被周边工具验证过的组合。

2. 系统总览：从相机到爪尖的数据流长什么样

开始写代码之前，先把整个系统的数据流理清楚。端到端这里指的是从RGB-D图像输入到夹爪闭合输出的完整自动链路，而不是某个神经网络直接输出关节角度。机械臂抓取不是单靠一个模型就能稳定做好的事情，它需要感知、推理、规划、控制多个阶段紧密配合。

2.1 节点骨架与通信接口设计

这套系统的ROS 2节点划分如下：

• camera_node：负责驱动RGB-D相机，发布彩色图像、深度图像和点云数据，话题分别是/camera/color/image_raw、/camera/depth/image_raw、/camera/depth/points。
• detect_node：订阅彩色图像，运行目标检测模型（我这里用的YOLOv8，你也可以换成自己训练的检测器），输出物体的2D边界框，发布vision_msgs/Detection2DArray。
• grasp_pose_node：订阅彩色图像、点云和检测结果，通过抓取位姿估计模型或点云几何算法，计算物体在相机坐标系下的抓取位置和姿态，发布geometry_msgs/PoseStamped。
• task_manager：这是整个系统的“工头”节点，维护一个简单的状态机，状态依次为IDLE → DETECTING → PLANNING → EXECUTING → GRASPING → PLACING → IDLE。它会等待grasp_pose有效，然后把目标发送给MoveIt 2的move_group节点。
• move_group：MoveIt 2核心节点，负责运动规划和碰撞检测，当收到目标位姿后生成机械臂运动轨迹。
• robot_controller：基于ros2_control的关节控制器，执行轨迹并反馈状态到task_manager。

数据流可以这样理解：相机就像人的眼睛，detect_node和grasp_pose_node像大脑视觉皮层，task_manager像前额叶做决策，move_group像运动皮层负责规划动作，robot_controller才是最终把信号送到肌肉的脊髓。每一层的输出质量都直接影响下一层能不能正常工作，所以整个系统的调试重点就是保证每一层输出的消息不仅“有值”而且“可信”。

2.2 端到端时序约束：如何保证抓取动作不超时

实际系统里最容易被忽略的是时序。相机一般跑30帧每秒，检测模型在一张图上可能需要50毫秒，抓取姿态估计又要消耗100到200毫秒，MoveIt规划可能需要几百毫秒，机械臂执行又需要两三秒。如果task_manager总是使用最新一帧的抓取位姿，很可能出现一种情况：视觉算出一个点，机械臂正准备过去，但目标物体已经被挪走了，或者机械臂自身运动导致相机视野变化，整个抓取动作落空。

我的做法是在task_manager里加一个**“目光锁定”机制**：当检测到目标后，先记录当前时间戳，然后等待连续3帧的姿态估计结果，如果这三帧的抓取位置距离波动小于1厘米，且姿态变化小于5度，才认为这个目标位姿可靠，再发送给move_group。同时，把发送到move_group的姿态做一个简单的时间戳补偿——如果目标物体在传送带上移动，还需要根据物体速度外推它在规划完成那一刻的预计位置。这样虽然多花了一点等待时间，但抓取成功率从刚开始的60%左右提升到接近90%。

3. Jazzy环境搭建与依赖安装实录

这一节记的是我实际从零装环境的完整过程。Jazzy不像Humble那么老，很多教程都覆盖了，但真正装起来还是有一些顺序和依赖坑，尤其是跟MoveIt 2和相机驱动混装的时候。

3.1 全新Ubuntu 24.04上装Jazzy的合理顺序

先说结论，推荐顺序是：先装Ubuntu 24.04最小化系统，再装ROS 2 Jazzy桌面版，然后装MoveIt 2，最后装相机驱动和仿真组件。

安装ROS 2 Jazzy，首先添加ROS 2 apt源：

sudo apt install software-properties-common curl sudo add-apt-repository universe sudo apt update sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null sudo apt update sudo apt install ros-jazzy-desktop python3-rosdep python3-colcon-common-extensions

装完之后别忘了初始化rosdep：

sudo rosdep init rosdep update

随后给当前用户加环境变量，我习惯把这行写到~/.bashrc里：

source /opt/ros/jazzy/setup.bash

这里要注意，千万不要同时source另一个ROS发行版的环境，比如旧的/opt/ros/humble/setup.bash。两个版本的环境变量会相互覆盖，轻则导致ros2 topic list看到的节点不对，重则出现链接库符号冲突，程序一跑就崩溃。我排查过好几个“玄幻”问题，最后都是环境串了。

3.2 MoveIt 2与ros2_control的版本坑

装上基础ROS 2之后，接着安装MoveIt 2：

sudo apt install ros-jazzy-moveit

再安装ros2_control相关控制器：

sudo apt install ros-jazzy-ros2-control ros-jazzy-ros2-controllers

如果你用的是常见的UR5e或者自建六轴机械臂模型，还需要生成一个配合ros2_control的URDF/XACRO描述文件。这里最大的坑是MoveIt 2的movelt_config包通常和ros2_control的控制器配置不在同一个坐标系下。Jazzy版本里MoveIt 2的move_group默认通过ros2_control的joint_trajectory_controller来执行轨迹，所以你的ros2_controllers.yaml里必须有一个joint_trajectory_controller并且声明了正确的关节名。如果名称不匹配，move_group能规划但执行时反馈错误，表现为机械臂一动不动，或者动作到一半突然停住。

我建议先跑一次官方Demo来确认环境本身没问题：

ros2 launch moveit2_tutorials demo.launch.py

如果官方Demo能正常拖动规划，说明MoveIt 2核心没问题，接下来问题就在你自定义的URDF和控制器配置上。

3.3 把工程包导入工作空间的步骤

项目工程我按标准ROS 2工作空间组织：

grasp_ws/ ├── src/ │ ├── grasp_bringup/ # 启动文件，包含所有节点的launch │ ├── grasp_perception/ # 检测、位姿估计节点 │ ├── grasp_planning/ # MoveIt 2规划与执行封装 │ ├── grasp_bringup/ # 状态机 │ ├── robot_description/ # 机械臂URDF、MoveIt配置 │ └── camera_driver/ # 相机驱动封装

导入工作空间后编译：

cd ~/grasp_ws colcon build --symlink-install source install/setup.bash

用--symlink-install是为了方便调试Python节点，不用每次改代码都重新build。这一步看似简单，但经常有人忘记先安装系统级的colcon扩展，或者Python包缺失导致编译报错。如果遇到ModuleNotFoundError: No module named 'catkin_pkg'，安装python3-catkin-pkg和python3-rosdep就能解决。

4. 抓取核心实现：位姿估计与运动规划的关键细节

整个系统最核心的部分就是抓取位姿怎么算出来，以及MoveIt 2怎么在毫秒级生成一条安全轨迹。这两个问题涉及大量坐标系转换和参数调试，我单独拆开讲。

4.1 抓取位姿怎么算：从像素到抓取点

抓取位姿估计目前有两种主流做法：一种是纯几何方法，适合已知的规则物体；另一种是基于深度学习的方法，对任意物体泛化能力更好。我这套系统里两者都用到了，规则物体用点云几何，复杂物体用深度学习模型，通过一个节点内的策略选择器自动切换。

几何方法的思路很直接：

1. 从detect_node拿到物体在彩色图上的2D框。
2. 根据相机内参，把2D框中心点映射到深度图对应像素，取深度值，得到相机坐标系下的空间点。
3. 裁剪出该区域对应的点云子集，使用RANSAC平面分割找到支撑桌面平面，把物体点从桌面点中分离出来。
4. 对剩余物体点云计算包围盒或主成分分析，得到物体的中心位置和主方向，这就是抓取位姿。

代码上，坐标转换用tf2完成：

from tf2_ros import Buffer, TransformListener from geometry_msgs.msg import PoseStamped def pixel_to_camera_point(u, v, depth, camera_info): fx = camera_info.k[0] fy = camera_info.k[4] cx = camera_info.k[2] cy = camera_info.k[5] z = depth / 1000.0 # 如果深度单位是毫米 x = (u - cx) * z / fx y = (v - cy) * z / fy return [x, y, z]

对于深度学习方案，我封装过一个基于Contact-GraspNet的推理节点。输入是点云，输出是每个点的抓取置信度和抓取矩形的6D位姿。这个模型的输出在camera_link坐标系下，之后还需要用tf2变换到base_link或tool0，变换关系如果没配好，就会出现“机械臂抓空气”的经典问题。

这里有一个至关重要的点：抓取位姿的参考坐标系必须和机械臂规划时的规划坐标系一致。我统一使用base_link作为所有位姿目标的坐标系，这样move_group就不需要再关心相机在哪，只需把目标PoseStamped的header.frame_id设置成base_link。而相机到机械臂底座的外部参数，则通过手眼标定得到。

4.2 MoveIt 2的规划参数调优

拿到目标位姿后，下一步就是让MoveIt 2规划一条从当前关节角到目标位姿的无碰撞轨迹。我用的是MoveIt 2的Python接口。Jazzy里推荐用moveit_py，代码更现代，可以直接传MoveItPy对象：

from moveit_py import MoveItPy from geometry_msgs.msg import PoseStamped moveit = MoveItPy(node, "arm_group") planning_scene_monitor = moveit.get_planning_scene_monitor() arm = moveit.get_plan_group("arm_group") goal_pose = PoseStamped() goal_pose.header.frame_id = "base_link" goal_pose.pose.position.x = 0.45 goal_pose.pose.position.y = 0.0 goal_pose.pose.position.z = 0.3 goal_pose.pose.orientation.w = 1.0 plan_result = arm.plan(goal_pose) if plan_result: arm.execute(plan_result.trajectory)

这里有两个参数我花了很久才调好：

规划时间上限。默认的0.5秒在某些复杂场景下不够，容易导致找不到路径直接失败。我实际上把OMPL的timeout设成了2到3秒，但并不意味着每次都要等这么久，大多数简单场景0.2秒就能出结果。保守的时间上限能显著提高复杂工位下的成功率。

允许碰撞矩阵。默认情况下MoveIt会严格检测所有碰撞，但在末端执行器靠近目标物体时，如果目标物体没有加入PlanningScene，规划器会误判为无碰撞，导致执行时直接撞过去。反过来，如果你把目标物体加入PlanningScene，又会因为物体点云误差导致规划器认为无法接近。所以我采用了一个折中：把物体的点云缩小2毫米后加入PlanningScene，同时在末端执行器和物体之间设置一个允许碰撞矩阵。这样既保证大部分手臂部位不碰撞，又给夹爪留出一点点咬合空间。

4.3 执行阶段的视觉反馈与力觉保护

规划执行不是“一发指令就撒手不管”。我在主动抓取执行阶段加入了视觉伺服微调：

1. 机械臂先运动到预抓取位置，距离目标约10厘米。
2. 此时相机重新采集一帧图像，再次估计目标物体的中心位置。
3. 如果新位置和规划时位置偏差大于2毫米，就通过MoveIt的Servo功能发布一个小的笛卡尔速度命令，把末端执行器往目标偏差方向微调。
4. 微调完成后，控制夹爪闭合，并用关节电流估算夹爪是否真正夹到物体。

视觉伺服微调这段逻辑最容易被忽略，但它恰恰是真实场景中成败的分水岭。因为位姿估计的模型推理有延迟，机械臂运动又存在控制误差，一次规划的目标位姿到真正执行时可能已经不够准确。增加最后一帧的反馈校准，能显著提升抓取可靠性。

5. 调试实录：我在这套系统上踩过的五个坑

代码写完只是开始，调试才是真正花时间的地方。这里记录五个让我印象深刻的坑，每个都附上排查链路和解决方法，希望能帮你在复现时少走弯路。

5.1 第一坑：所有话题正常，但抓取位姿全是NaN

系统第一次跑起来，detect_node能检测到物体，grasp_pose_node也不报错，但发布出的PoseStamped里position全是NaN。我先是反复看代码逻辑，确认数值计算没问题，后来用ros2 topic echo /grasp_pose --once看到时间戳是正常的，但坐标系中的变换始终不对。

排查链路：先用rqt_tf_tree查看TF树，发现相机到机械臂底座的static_transform_publisher没有启动。grasp_pose_node在把点转换到base_link时，tf2拿不到相机外参，于是返回NaN。解决方法是检查URDF文件里是否包含了相机link和base_link之间的固定变换，如果没有，就单独写一个TF2静态变换节点，确保相机外参在启动时被发布。

教训是：所有坐标变换相关的问题，先用TF树排查，不要先从算法代码开始查。TF树完整了，很多NaN问题自然消失。

5.2 第二坑：规划器长时间搜不到路径，但手工拖拽轨迹没问题

用MoveIt Studio调试时，我手动拖拽机械臂末端能到达抓取点，但用OMPL规划却总是搜索超时。一开始怀疑是规划组设置错误，反复检查碰撞矩阵都没有用。

后来发现是PlanningScene里没有添加感知点云碰撞物体。我的相机点云是不断发布的，但move_group默认不会自动订阅点云来更新场景。必须通过PlanningScene接口将点云添加成CollisionObject，或者使用PointCloudOctomapUpdater来把点云转为占用地图。没有这一步，规划器眼里环境是空的，于是它会非常“保守”或者“迷惑”，找不到一条合理的避让路径。

解决方法是配置MoveIt的sensors参数，在move_group.launch里加入点云传感器配置，让move_group订阅点云话题并自动更新碰撞场景。之后规划成功率有了质的提升。

5.3 第三坑：仿真里抓得很稳，真实环境却总是差一点

在Gazebo Harmonic里测试时，系统抓取非常流畅。换到真实机械臂后，同样的流程频繁出现“夹爪擦着物体边滑过去”的现象。我反复检查了相机标定、手眼矩阵，都没发现明显错误，但成功率就是上不去。

最后用棋盘格标定板重新做了手眼标定，发现之前用的标定程序在处理畸变时使用了错误的相机内参，导致距离误差在30厘米处达到了约1.5厘米。1.5厘米对于视觉抓取来说，已经足够让夹爪落空。

调整之后还有一个附加手段：在抓取前加一个“最后一步”的视觉确认。也就是前面4.3说的视觉伺服微调，让机械臂在靠近目标后，用近距离深度图再算一次抓取点。这个改动直接让真实环境下的抓取成功率从70%左右提升到了接近95%。如果你在每个项目里都只做一步就抓，真实环境中基本不可能稳定复现仿真效果。

5.4 第四坑：运行几分钟后move_group占用CPU飙升，系统开始掉帧

长时间运行测试中，发现move_group的CPU占用会逐渐升高，从初始的5%涨到80%，最后整个系统交互响应变慢。用top看线程栈，发现主要消耗在碰撞检测模块。

原因有两点：一是点云传感器更新的频率太高，move_group每收到一帧点云就触发一次碰撞场景重建，而点云帧率是30Hz，直接就饱和了；二是点云的体素滤波分辨率设得太高，Octomap的格子过密，碰撞检测计算量指数增加。

解决方法是把点云订阅的QoS depth改为只保留最近1帧，同时在预处理中降低点云分辨率，把体素大小从0.005米调整到0.01米。这样碰撞场景更新频率降到5Hz，CPU占用稳定在20%以下，对抓取精度几乎没有影响。这种“性能优化”不能靠拍脑袋降低参数，要结合你自己的机械臂工作空间大小来权衡。工作空间范围小、物体尺寸大，就可以更激进地降低点云分辨率。

5.5 第五坑：QoS不匹配，视觉节点和规划节点经常丢消息

在调试过程中，detect_node偶尔会收不到图像，grasp_pose_node也时不时丢点云。我做了一个简单测试：ros2 topic info /camera/depth/points --verbose，发现发布端的QoS是SensorDataQoS，而订阅端grasp_pose_node用的是默认Reliable QoS。两者的QoS策略不匹配时，DDS会直接断开连接，而不是降级传输，导致订阅端收不到任何数据。

这个坑很隐蔽，因为报错信息不会特别明显。我的统一规范是：感知类话题（图像、点云）在发布和订阅端都使用SensorDataQoS，规划指令类话题使用Reliable，状态反馈使用SystemDefault。在代码里可以配置以下QoS：

from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy, DurabilityPolicy sensor_qos = QoSProfile( depth=1, reliability=ReliabilityPolicy.BEST_EFFORT, history=HistoryPolicy.KEEP_LAST, durability=DurabilityPolicy.VOLATILE )

发布端和订阅端都设置成相同的策略后，丢消息问题彻底消失。

6. 性能与稳定性优化：从“能跑”到“能一直跑”

很多抓取demo在演示时很流畅，但连续运行几个小时甚至一个班次后就开始出现各种问题。这一节我总结些关于ROS 2 executor和DDS参数调优的经验，把系统从“能跑”推向“能一直跑”。

6.1 节点执行器与回调分组

ROS 2的默认执行器是SingleThreadedExecutor，所有订阅回调都在同一个线程里按顺序执行。如果你的感知节点不仅要处理图像，还要运行模型推理，回调时间会很长，直接阻塞同一节点的其他话题处理，甚至拖累整条链路的实时性。

我把关键节点改为自定义的MultiThreadedExecutor，并给同一节点内不同的回调设置不同QoS抢占策略。比如detect_node里，图像订阅回调设置qos.depth=2，推理结果发布使用独立线程。同时，我把整个系统的executor数量控制在两个：一个负责感知类节点（高频率、低延迟），一个负责规划和状态机（低频率、高可靠性）。避免所有节点挤在一个线程池里互相争抢。

一个可运行的启动配置片段：

from rclpy.executors import MultiThreadedExecutor from rclpy.callback_groups import MutuallyExclusiveCallbackGroup, ReentrantCallbackGroup perception_group = MutuallyExclusiveCallbackGroup() planning_group = ReentrantCallbackGroup()

在每个节点创建订阅和定时器时，把callback_group参数分别绑到对应组别。这样感知回调不会阻塞规划动作下发，规划执行期间也不会漏掉相机的新帧。

6.2 QoS与丢帧应对

除了前面提到的QoS匹配，还需要考虑丢帧时的系统行为。图像检测模型在帧率不稳定的情况下，偶尔丢一帧是正常的。我在detect_node里增加了一个“帧超时监控”：如果连续2秒没有新的图像消息，节点进入DEGRADED状态，并发布一个诊断消息让task_manager暂停抓取，防止机器人对陈旧数据作出反应。

这个机制防止了一个很危险的场景：当相机因为USB带宽不足偶尔掉帧，task_manager还在用几分钟前的检测结果去指挥机械臂移动。稳定运行的优先级高于速度，该暂停就暂停。

6.3 长时间运行的看门狗与日志策略

系统连续跑了一天一夜后，最容易出现的是某个节点被莫名杀掉，或者move_group失去响应。我开始在launch文件里给每个节点加上respawn为true，让被异常终止的节点自动重启。同时用一个轻量的诊断节点，周期性检查每个节点的活跃话题，如果某个必要话题5秒内没有新消息，就把状态机置为FAULT并发送告警。

日志方面，Jazzy的ros2 bag record很好用，我会在工作时录制关键话题，出现问题后离线回放节点消息，而不需要盯着终端看一堆DEBUG输出。实际项目里我还把日志写到文件，配合journalctl查看系统级错误。这些看起来不“酷”的运维手段，反而能让抓取系统真正走进落地环节。

7. 这套系统后续能怎么扩展

工程打包成zip后，不只是给我自己复用，也方便有类似需求的朋友在此基础上改。目前这套框架已经适配过两种不同的机械臂URDF，只要把robot_description和控制器配置换掉，系统感知和状态机代码基本不用动。

如果你想把它从固定工位扩展到移动底盘上，需要额外增加底盘里程计与机械臂基座位姿的耦合，task_manager里还需要增加一个“移动-抓取”的协同状态。如果你想把抓取目标从规则物体推广到任意无序堆叠物体，可以在grasp_pose_node里替换成更强的抓取模型，但记得在线推理的时间要控制在300毫秒以内，否则时序补偿会变得非常吃力。

这套系统的完整代码结构、launch文件和说明文档都在zip包里，我自己在实际使用中还有一个体会：抓取系统的价值不在于某个单点算法有多新，而在于整条链路能否在连续运行中保持稳定。先把环境、TF、QoS这些“不性感”但又决定成败的基础打牢，再往上堆模型和算法，遇到的坑会少得多。

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