📚 课程目录第3章节点通信机制

3. 节点通信机制

ROS2 的节点（Node）并非孤岛，真正的机器人应用价值体现在节点之间的协作与数据交换中。ROS2 提供了三种核心的通信机制——话题（Topic）、服务（Service）和动作（Action），它们分别适用于不同的交互场景。理解这三种接口的编程模型，是编写可维护、可扩展控制器节点的基础。

3.1 核心原理：三种通信机制的本质区别

三种机制在通信模式、数据流向和实时性上存在显著差异，选择错误的机制往往会导致系统设计缺陷。下表从工程角度对比了它们的核心特征：

维度	话题（Topic）	服务（Service）	动作（Action）
通信模式	发布/订阅（异步，多对多）	请求/响应（同步，一对一）	目标/反馈/结果（异步+同步混合）
数据流向	单向连续流	双向一次性交互	双向长时任务交互
实时性	高（持续更新）	中（等待响应）	低（适合长时间执行）
典型用途	传感器数据、状态发布	查询参数、触发开关	导航、机械臂运动控制
失败处理	无（订阅者自行判断超时）	客户端可捕获异常	支持取消、抢占、超时

在控制器节点项目中，话题通常用于高频状态反馈（如关节角度、速度），服务用于低频率的配置修改（如切换控制模式），而动作则用于需要持续监控进度的复杂任务（如点到点运动）。

选型口诀：持续流用话题，一问一答用服务，任务执行带反馈用动作。若任务可能被取消或需要中途反馈，务必使用动作而非服务。

3.2 话题编程接口：Publisher 与 Subscription

话题是 ROS2 中最常用的通信方式，其编程接口围绕 rclcpp::Publisher 和 rclcpp::Subscription 展开。在控制器节点中，我们通常需要发布关节状态，同时订阅目标速度指令。

创建发布者的核心流程如下：

在节点构造函数中调用 create_publisher<接口类型>("话题名", QoS深度)。
使用 publish(message) 方法发送数据，消息类型需与模板参数一致。
对于周期性发布，常配合 wall_timer 实现固定频率发送。

// 发布关节角度（示例）
class JointController : public rclcpp::Node {
public:
  JointController() : Node("joint_controller") {
    // 创建发布者，话题名 /joint_states，队列深度 10
    joint_pub_ = this->create_publisher<sensor_msgs::msg::JointState>(
      "/joint_states", 10);
    // 创建定时器，每 10ms 发布一次（100Hz）
    timer_ = this->create_wall_timer(
      std::chrono::milliseconds(10),
      std::bind(&JointController::publish_joint_state, this));
  }

private:
  void publish_joint_state() {
    sensor_msgs::msg::JointState msg;
    msg.header.stamp = this->now();
    msg.name = {"joint1", "joint2"};
    msg.position = {current_pos1_, current_pos2_};
    joint_pub_->publish(msg);
  }
  rclcpp::Publisher<sensor_msgs::msg::JointState>::SharedPtr joint_pub_;
  rclcpp::TimerBase::SharedPtr timer_;
};

订阅端的创建同样简单，使用 create_subscription<类型>(话题名, QoS, 回调函数)。回调函数会在每次收到消息时被触发，注意回调中不应执行耗时操作，否则会阻塞节点的事件循环。

3.3 服务编程接口：Client 与 Server

服务用于需要即时响应的请求-应答场景。在控制器中，典型的服务包括“使能电机”“切换控制模式”“读取当前参数”。服务接口由 .srv 文件定义，包含请求（Request）和响应（Response）两部分。

服务端（Server）的创建步骤：

定义回调函数，接收请求并返回响应。
使用 create_service<接口类型>("服务名", 回调) 注册服务。

// 服务端示例：切换控制模式
bool switch_mode(
  const std::shared_ptr<controller_interfaces::srv::SwitchMode::Request> req,
  std::shared_ptr<controller_interfaces::srv::SwitchMode::Response> res) {
  if (req->mode == "position") {
    current_mode_ = ControlMode::POSITION;
    res->success = true;
    res->message = "已切换到位置模式";
  } else {
    res->success = false;
    res->message = "不支持的模式: " + req->mode;
  }
  return true;
}

// 在构造函数中注册
mode_srv_ = create_service<controller_interfaces::srv::SwitchMode>(
  "switch_mode", &switch_mode);

客户端（Client）调用服务时，需要注意同步调用 call() 会阻塞当前线程，在回调中调用容易造成死锁。推荐使用异步调用 async_send_request() 配合回调处理结果。

常见陷阱：在 ROS2 中，服务客户端调用前必须等待服务端就绪，否则会抛出异常。使用 wait_for_service() 方法确认服务可用后再发起请求，避免启动时序问题。

3.4 动作编程接口：Action Server 与 Action Client

动作机制是 ROS2 中最复杂的通信接口，它由目标（Goal）、反馈（Feedback）和结果（Result）三部分组成。动作适用于执行时间较长、需要中途反馈且可能被取消的任务，例如机械臂的轨迹规划执行。

动作服务端的实现需要继承 rclcpp_action::Server<动作类型>，并实现三个关键回调：

handle_goal：接收目标并决定接受或拒绝。
handle_cancel：处理取消请求。
execute：执行实际任务，期间可发布反馈。

// 动作服务端核心结构（伪代码）
rclcpp_action::GoalResponse handle_goal(
  const GoalUUID& uuid, std::shared_ptr<const MoveToPose::Goal> goal) {
  RCLCPP_INFO(get_logger(), "收到目标: x=%f, y=%f", goal->x, goal->y);
  // 检查目标是否合法
  if (goal->x > 10.0) return rclcpp_action::GoalResponse::REJECT;
  return rclcpp_action::GoalResponse::ACCEPT_AND_EXECUTE;
}

rclcpp_action::CancelResponse handle_cancel(
  const std::shared_ptr<GoalHandleMoveToPose> goal_handle) {
  RCLCPP_INFO(get_logger(), "收到取消请求");
  return rclcpp_action::CancelResponse::ACCEPT;
}

void execute(const std::shared_ptr<GoalHandleMoveToPose> goal_handle) {
  // 执行运动控制循环
  while (rclcpp::ok() && !goal_handle->is_canceling()) {
    // 计算并发布反馈
    auto feedback = std::make_shared<MoveToPose::Feedback>();
    feedback->progress = current_progress_;
    goal_handle->publish_feedback(feedback);
    // 判断是否到达目标
    if (reached_goal()) break;
  }
  // 设置最终结果
  auto result = std::make_shared<MoveToPose::Result>();
  result->success = true;
  goal_handle->succeed(result);
}

动作客户端则通过 async_send_goal() 发送目标，并注册反馈回调和结果回调。客户端可以随时发送取消请求，服务端需要响应取消并停止执行。

3.5 案例：控制器节点中的混合通信设计

以一个典型的六轴机械臂控制器节点为例，展示三种通信机制如何协同工作：

话题：以 100Hz 发布 /joint_states（关节角度、速度），供可视化与运动学计算节点订阅。
话题：订阅 /joint_cmd（目标关节位置），接收来自规划器的高频指令。
服务：提供 /enable_motor 服务，用于安全使能或失能电机驱动器。
服务：提供 /get_controller_info 服务，返回当前控制频率、PID 参数等。
动作：提供 /move_to_pose 动作，接收末端目标位姿，执行轨迹插补并反馈进度。

这种设计将高频数据流（话题）、低频控制指令（服务）和长时任务（动作）分离，各司其职，避免了单一通信机制带来的阻塞或实时性不足问题。

3.6 误区与复盘：接口选择与实现中的常见问题

在实际开发中，以下问题经常导致调试困难或系统性能下降：

误区	后果	正确做法
用服务传输高频传感器数据	服务端阻塞，数据延迟严重	改用话题，利用 QoS 控制频率
在话题回调中执行耗时计算	回调堆积，节点响应变慢	回调只做数据拷贝，计算放入独立线程
动作执行中不检查取消请求	客户端无法中断任务，可能造成危险	循环中调用 `is_canceling()` 并退出
服务端未启动就调用客户端	抛出异常或连接失败	使用 `wait_for_service()` 确保就绪
所有通信都用同一个 QoS 深度	高频话题丢帧或低频话题内存浪费	根据数据频率和重要性设置 QoS（如传感器用 5，指令用 1）

复盘一个典型问题：某控制器节点在接收 /joint_cmd 时，由于回调中直接执行了逆运动学计算（耗时约 50ms），导致话题回调阻塞，后续指令无法及时处理，机械臂运动出现明显卡顿。解决方案是将逆运动学计算放入独立线程，回调仅负责将指令存入环形缓冲区，计算线程从缓冲区取数据执行，从而保证了指令接收的实时性。

  设计复盘要点：在控制器节点中，话题回调应保持轻量级（微秒级），所有耗时操作（如运动学计算、轨迹插补）应放入独立执行线程。服务端回调同样应快速返回，若需长时间处理，考虑使用动作替代服务。动作的 execute 函数天然运行在独立线程中，适合承载复杂控制算法。

掌握三种通信接口的编程范式，并理解其适用边界，是构建稳定、高效 ROS2 控制器节点的关键。在实际项目中，建议先绘制通信拓扑图，明确每个接口的数据流向、频率和延迟要求，再进行编码实现，这样可以显著减少后期集成时的通信问题。