ROS 2 节点通信基础

警告：历史笔记的适用范围 本文由 2025 年的学习记录整理而来，重点是通信模型而非某个固定发行版的安装命令。ROS 2 Foxy 已结束支持；新项目应选择仍受支持且与设备、PX4 和仿真器匹配的发行版，并以 ROS 2 官方安装文档为准。

先划分节点职责

ROS 2 节点是独立运行的功能单元。一个节点应围绕一项清晰职责，例如读取传感器、估计状态、规划轨迹或驱动执行器。将节点拆分为可独立启动、观察和测试的单元，通常比把所有功能放进一个可执行文件更容易定位问题。

在 C++ 中，rclcpp 是常用客户端库。最小节点的生命周期是：初始化 ROS 上下文、创建节点和通信实体、进入 spin 处理回调，最后关闭上下文。日志应使用节点自己的 logger，便于按节点名和级别过滤。

rclcpp::init(argc, argv);
auto node = std::make_shared<rclcpp::Node>("telemetry_node");
RCLCPP_INFO(node->get_logger(), "node started");
rclcpp::spin(node);
rclcpp::shutdown();

四种常用交互方式

机制	数据方向与时序	适合的场景	常见误用
话题（topic）	发布者向任意订阅者异步发送	传感器、状态、周期性命令	把必须确认的请求做成话题
服务（service）	客户端请求，服务端返回一次响应	查询、一次性配置、短操作	在服务回调中阻塞长任务
参数（parameter）	节点配置的键值对	阈值、设备名、运行模式	用参数传输高频运行数据
动作（action）	目标、反馈、结果与取消	导航、机械臂动作等长任务	用服务替代需要取消和进度的任务

选择机制时先问两个问题：调用者是否需要确认结果，以及操作是否会持续较长时间。周期数据通常使用话题；短的请求—响应使用服务；需要进度、取消或最终结果的任务使用动作。

话题：先对齐名称、类型和 QoS

发布者和订阅者必须使用同一消息类型，话题名称也应在命名空间解析后保持一致。队列深度不是“可靠性开关”：它只决定本地可缓存的样本数量。对于控制、传感器和跨网络链路，还要显式评估 QoS 的可靠性、持久性与历史策略。

auto publisher = node->create_publisher<std_msgs::msg::String>("status", 10);
auto subscription = node->create_subscription<std_msgs::msg::String>(
  "status", 10,
  [](std_msgs::msg::String::ConstSharedPtr message) {
    RCLCPP_INFO(rclcpp::get_logger("status_listener"), "%s", message->data.c_str());
  });

用 ros2 topic list、ros2 topic info -v <topic> 和 rqt_graph 检查实际图结构。发现“收不到消息”时，先检查解析后的话题名、消息类型和 QoS，再检查节点是否持续运行。

服务、参数和动作的边界

服务端应快速返回；耗时工作可由服务接受请求后交给状态机、动作或后台任务处理。客户端在等待服务出现时应响应退出信号和超时，而不是无限阻塞。

参数在节点启动时声明，并通过 YAML 或 launch 文件注入。参数文件适合保存可审计的配置，不应包含密码、令牌或设备私有地址。动作的目标、反馈和结果应定义为稳定接口；客户端需要能处理服务端拒绝目标、取消请求和异常结束。

下一步

先用一个发布者和订阅者验证本机通信，再添加服务或动作，并把启动顺序、参数和命名空间写进 launch 文件。工作空间构建和测试命令见 ROS 2 工作空间编译与运行。PX4 与仿真器的版本匹配则见 PX4 与 Gazebo 仿真环境复现。