2. ROS2基础回顾

在进入目标跟随这一综合性机器人应用之前，必须先夯实ROS2的基础框架。目标跟随系统本质上是一个多节点协作的分布式计算系统：激光雷达或深度相机节点负责感知，TF树负责坐标变换，速度控制节点负责输出指令。如果对ROS2的通信机制理解不透彻，后续在调试话题不匹配、服务超时、动作取消等问题时会寸步难行。本章将系统梳理ROS2的五大核心通信机制（节点、话题、服务、动作、参数），并完整演示从创建工作空间到编译运行的全流程，为后续章节的工程实践打下坚实基础。

上图展示了ROS2中节点与四种通信机制的关系，以及从工作空间到运行的完整链路。节点是ROS2中的最小计算单元，所有通信都围绕节点展开。话题用于连续数据流传输，服务用于同步请求-响应，动作用于长时间任务且支持取消和反馈，参数则用于节点运行时的配置调整。理解这些机制的区别与适用场景，是设计目标跟随系统的前提。

2.1 核心通信机制：原理与适用场景

2.1.1 节点与话题：异步数据流的基石

节点（Node）是ROS2中可执行文件运行时的实例化对象，每个节点负责特定的功能模块。在目标跟随系统中，典型的节点包括：camera_driver（图像采集）、detection_node（目标检测）、tf_broadcaster（坐标变换发布）、velocity_controller（速度控制）。节点之间通过话题（Topic）进行异步通信，话题采用发布/订阅模式，发布者将消息推送到话题，订阅者从话题接收消息。这种模式非常适合传感器数据流，例如相机图像以30Hz频率发布，速度控制器以10Hz频率订阅检测结果。

话题通信的关键特性是解耦性：发布者和订阅者互不感知对方的存在，只需知道话题名称和消息类型。这使得系统可以灵活地增加或移除节点，例如在调试时增加一个rqt_image_view节点订阅图像话题，而不影响原有链路。但这也带来一个隐患：如果发布者异常退出，订阅者不会收到任何通知，可能导致控制节点使用过期数据。因此在实际工程中，需要利用QoS（Quality of Service）策略来管理数据可靠性。

2.1.2 服务与动作：同步请求与长时任务

服务（Service）采用客户端-服务器模式，客户端发送请求并阻塞等待响应，适用于一次性、短时、需要确认的操作。例如，在目标跟随系统中，可以使用服务来动态切换跟随目标（switch_target服务），客户端发送目标ID，服务器确认后返回切换结果。服务通信是同步的，如果服务器处理时间过长，客户端会一直阻塞，因此不适合用于持续的数据流。

动作（Action）是ROS2中专门为长时间任务设计的通信机制，它结合了话题的异步性和服务的反馈能力。动作由三部分组成：目标（Goal）、反馈（Feedback）和结果（Result）。例如，机器人执行"跟随目标移动2米"这个动作时，客户端发送目标，服务器在执行过程中持续发布反馈（当前距离、速度），最终返回结果（成功或失败）。动作支持取消操作，这在目标丢失或紧急避障时至关重要。

2.1.3 参数：运行时配置的灵活机制

参数（Parameter）是ROS2中用于节点运行时配置的键值对机制。每个节点可以维护自己的参数列表，参数可以在节点启动时通过命令行设置，也可以在运行时动态修改。在目标跟随系统中，参数的使用非常广泛：max_linear_speed（最大线速度）、min_detection_score（最小检测置信度）、target_frame（目标坐标系名称）等。使用参数而非硬编码的好处是，可以在不重新编译代码的情况下调整系统行为，极大提升了调试效率。

参数还支持回调机制，当参数被外部修改时，节点可以注册回调函数来响应变化。例如，当操作员通过RQT动态调整PID参数时，速度控制器节点可以立即感知并更新控制律，无需重启节点。

2.2 工作空间与功能包：工程组织的基本单元

2.2.1 工作空间结构与功能包创建

ROS2的工作空间（Workspace）是一个包含多个功能包的目录结构，通常命名为dev_ws或ros2_ws。标准的工作空间包含src（源码目录）、build（编译中间文件）、install（安装产物）和log（日志）四个子目录。其中src目录存放所有功能包源码，是开发者主要操作的目录。

功能包（Package）是ROS2中代码组织的基本单元，一个功能包可以包含节点源码、配置文件、启动文件、消息定义等。创建功能包使用ros2 pkg create命令，需要指定包名、依赖项和构建类型。对于C++使用ament_cmake，对于Python使用ament_python。在目标跟随项目中，我们通常会创建多个功能包：robot_perception（感知）、robot_tf（坐标变换）、robot_control（控制）。

# 创建工作空间
mkdir -p ~/dev_ws/src
cd ~/dev_ws/src

# 创建C++功能包（依赖rclcpp和geometry_msgs）
ros2 pkg create robot_control --build-type ament_cmake --dependencies rclcpp geometry_msgs

# 创建Python功能包（依赖rclpy和sensor_msgs）
ros2 pkg create robot_perception --build-type ament_python --dependencies rclpy sensor_msgs

2.2.2 编译与运行流程

ROS2使用colcon作为统一的编译工具，替代了ROS1中的catkin。编译流程分为三个步骤：配置（识别功能包和依赖）、编译（生成可执行文件和库）、安装（将产物复制到install目录）。编译完成后，需要source安装目录下的setup.bash脚本，使当前终端能够找到新编译的功能包和可执行文件。

# 编译整个工作空间
cd ~/dev_ws
colcon build --symlink-install

# 仅编译指定功能包（节省时间）
colcon build --packages-select robot_control

# 使能环境
source install/setup.bash

# 运行节点
ros2 run robot_control velocity_controller

2.3 案例拆解：构建一个最小目标跟随通信框架

为了将上述概念串联起来，我们设计一个简化的目标跟随通信框架。该框架包含三个节点：fake_detector（模拟检测器，发布目标位置）、tf_publisher（发布TF变换）、velocity_controller（订阅目标位置并发布速度指令）。这个案例虽然不包含真实感知，但完整展示了节点间通过话题和TF协同工作的模式。

场景约束：假设机器人底盘最大线速度为0.5m/s，目标检测频率为20Hz，控制频率为10Hz。初始现象是三个节点独立运行，但速度控制器收不到检测数据。通过ros2 topic list和ros2 topic echo排查，发现fake_detector发布的话题名是/target_position，而velocity_controller订阅的是/target_pose，名称不匹配。

分析过程：话题名称不匹配是ROS2开发中最常见的问题。使用ros2 topic info /target_position查看发布者和订阅者数量，可以快速定位问题。修正话题名称后，速度控制器开始接收数据，但发现速度指令波动剧烈。进一步检查发现，fake_detector发布的消息时间戳不稳定，导致控制节点计算出的速度变化率过大。

解决方案：在速度控制器中增加低通滤波，对目标位置进行平滑处理。同时，在fake_detector中固定消息发布频率，使用rclcpp::Rate控制循环频率。修改后的系统运行平稳，速度指令曲线平滑。

复盘经验：这个案例揭示了ROS2开发的三个关键点：第一，话题名称必须严格一致，建议使用ros2 topic list和ros2 topic info进行验证；第二，消息的时间戳和发布频率直接影响控制质量，应使用rclcpp::Rate保证稳定频率；第三，控制节点应对输入数据进行滤波处理，避免噪声直接传递到执行器。

2.4 常见误区与总结复盘

在ROS2基础使用中，初学者常犯以下错误，这些错误在目标跟随开发中会放大为严重问题：

• 混淆话题和服务：试图用话题实现请求-响应，或用服务传输高频数据。话题适合流式数据，服务适合一次性操作，动作适合长时任务。
• 忽略QoS设置：默认的QoS可能导致订阅者收不到数据。例如，发布者使用Best Effort，订阅者使用Reliable，会导致消息丢失。在传感器数据场景，应统一使用SensorDataQoS。
• 忘记source环境：新终端未source导致找不到功能包。建议在.bashrc中配置，但注意多工作空间顺序。
• 编译时未处理依赖：功能包缺少依赖声明，导致编译失败。使用ros2 pkg create时通过--dependencies参数声明，或在package.xml中手动添加。
• 参数硬编码：将阈值、速度限制等写在代码中，调试时需反复编译。应使用参数机制，通过命令行或配置文件动态调整。