第三章 ROS核心概念：节点、话题、服务、参数服务器

聊到ROS，很多人第一反应就是“分布式”、“松耦合”。但说白了，这些高大上的词落地到代码里，就是四个核心概念：节点、话题、服务、参数服务器。我做了这么多年机器人系统，见过太多新手在这四个概念上栽跟头。今天咱们就把它们彻底捋清楚。

一句话总结：节点是干活的人，话题是广播喇叭，服务是电话客服，参数服务器是公共黑板。

ROS四大核心概念关系图 ROS 核心概念关系图 ROS Master 节点 A 节点 B 节点 C 话题 /cmd_vel 服务 /get_pose 参数服务器 通信机制说明 话题：发布/订阅模式，一对多，异步通信 服务：请求/响应模式，一对一，同步通信 参数服务器：全局键值对存储，运行时配置

3.1 节点（Node）—— 系统的“工人”

节点是ROS里最小的执行单元。每个节点就是一个独立的进程，负责完成某一项具体任务。比如一个节点专门读激光雷达数据，另一个节点专门做路径规划。

我个人习惯把节点想象成工厂里的工人。每个工人只干一件事，但所有工人配合起来，整个流水线就转起来了。这样做的好处很明显——某个节点挂了，不会拖垮整个系统。

我的经验：刚开始写ROS程序时，我总喜欢把所有功能塞进一个节点里。后来在调试一个多传感器融合项目时，一个节点的死循环导致整个系统卡死。从那以后，我坚持“一个节点只做一件事”的原则。

创建一个节点其实很简单。以C++为例：

#include <ros/ros.h>

int main(int argc, char **argv) {
    // 初始化节点，命名为"my_first_node"
    ros::init(argc, argv, "my_first_node");
    
    // 创建节点句柄
    ros::NodeHandle nh;
    
    // 设置循环频率为10Hz
    ros::Rate loop_rate(10);
    
    while (ros::ok()) {
        // 在这里做你的工作
        ROS_INFO("节点正在运行...");
        
        ros::spinOnce();
        loop_rate.sleep();
    }
    
    return 0;
}

你想想看，这段代码里最核心的就是 ros::init() 和 ros::NodeHandle。前者告诉ROS系统“我要注册一个工人”，后者是工人手里的工具包。

注意：节点名必须唯一。如果你启动两个同名节点，ROS会报错。我曾经在调试时忘了改节点名，结果两个节点互相抢占资源，折腾了一下午才发现问题。

3.2 话题（Topic）—— 系统的“广播站”

话题是ROS里最常用的通信方式。它采用发布/订阅模式，说白了就是一个节点发消息，其他节点收消息。发消息的叫发布者，收消息的叫订阅者。

举个例子：

  • 发布者：激光雷达驱动节点，不断发布扫描数据到 /scan 话题
  • 订阅者：SLAM建图节点，从 /scan 话题接收数据，构建地图

这里有个关键点：发布者和订阅者互相不知道对方的存在。它们只关心话题本身。这种解耦设计，让系统扩展变得非常灵活。

发布话题的代码长这样：

// 发布者示例
ros::Publisher pub = nh.advertise<std_msgs::String>("chatter", 1000);

std_msgs::String msg;
msg.data = "Hello ROS!";
pub.publish(msg);

订阅话题的代码：

// 订阅者示例
void chatterCallback(const std_msgs::String::ConstPtr& msg) {
    ROS_INFO("收到消息: %s", msg->data.c_str());
}

ros::Subscriber sub = nh.subscribe("chatter", 1000, chatterCallback);

避坑指南：我曾经在项目中遇到一个问题——订阅者收不到消息。查了半天发现是话题名拼写错了。ROS的话题名是大小写敏感的，/scan 和 /Scan 是两个完全不同的话题。这个坑我踩过，希望你别踩。

3.3 服务（Service）—— 系统的“客服热线”

话题是单向的、持续的广播。但有些场景你需要“问一句，答一句”。比如你让机器人报告当前位置，你不需要它一直广播位置，只需要在需要时问一次。这时候就该服务上场了。

服务采用请求/响应模式：

  • 客户端：发送请求，等待响应
  • 服务端：处理请求，返回结果

服务由两部分组成：请求（Request）和响应（Response）。定义服务的文件是 .srv 文件：

# 一个简单的服务定义
int64 a
int64 b
---
int64 sum

服务端实现：

bool add(robot_tutorial::AddTwoInts::Request &req,
         robot_tutorial::AddTwoInts::Response &res) {
    res.sum = req.a + req.b;
    ROS_INFO("请求: %ld + %ld", (long int)req.a, (long int)req.b);
    ROS_INFO("响应: %ld", (long int)res.sum);
    return true;
}

ros::ServiceServer service = nh.advertiseService("add_two_ints", add);

客户端调用：

robot_tutorial::AddTwoInts srv;
srv.request.a = 3;
srv.request.b = 4;

if (client.call(srv)) {
    ROS_INFO("结果: %ld", (long int)srv.response.sum);
} else {
    ROS_ERROR("服务调用失败");
}

我的建议：服务适合“偶尔调用、需要即时响应”的场景。比如获取当前状态、触发某个动作。但如果你需要高频数据流，比如每秒100次的传感器数据，请用话题。服务是同步阻塞的，高频调用会拖垮系统。

3.4 参数服务器（Parameter Server）—— 系统的“公共黑板”

参数服务器是一个全局的键值对存储。所有节点都可以读写它。我习惯把它想象成一块公共黑板——谁都可以在上面写东西，谁都可以看。

参数服务器适合存放：

  • 机器人运动学参数（轮距、轴距）
  • 传感器配置（激光雷达的扫描频率、相机分辨率）
  • PID控制参数
  • 系统运行模式（调试模式/生产模式）

读写参数的代码：

// 写参数
nh.setParam("robot_name", "turtlebot");
nh.setParam("max_speed", 0.5);

// 读参数
std::string robot_name;
double max_speed;

nh.getParam("robot_name", robot_name);
nh.getParam("max_speed", max_speed);

ROS_INFO("机器人: %s, 最大速度: %.2f", robot_name.c_str(), max_speed);

注意：参数服务器不是数据库。它存储在内存中，重启后数据会丢失。我曾经犯过一个错误——把标定数据存在参数服务器里，结果每次重启都要重新标定。后来我把标定数据存到YAML文件里，启动时加载到参数服务器。

3.5 四个概念的对比

概念 通信模式 方向性 典型场景 实时性
话题 发布/订阅 单向 传感器数据、状态广播 高（异步）
服务 请求/响应 双向 触发动作、查询状态 中（同步）
参数服务器 键值对 全局共享 配置参数、系统设置 低（按需读写）
节点 — — 执行具体任务 —

3.6 实际项目中的选择策略

说了这么多理论，咱们聊聊实际项目中怎么选。我总结了一个简单的决策树：

  1. 数据是持续产生的吗？ → 用话题（比如激光雷达数据、里程计数据）
  2. 需要一问一答吗？ → 用服务（比如获取当前位置、触发拍照）
  3. 是全局配置吗？ → 用参数服务器（比如PID参数、机器人型号）
  4. 以上都不是？ → 你可能需要重新设计系统架构

我的经验之谈：在做一个仓储机器人项目时，我一开始把所有通信都用了话题。结果发现“请求取货”这种操作用话题实现特别别扭——发布者发完消息就跑了，不知道服务端有没有处理。后来改成服务，代码清晰多了。选对通信方式，能让你的代码少一半的bug。

嗯，这四个概念是ROS的基石。理解透了，后面的章节就会轻松很多。记住：节点是工人，话题是广播，服务是电话，参数是黑板。下次写代码前，先想想你的场景适合哪种方式。

← 上一章 📖 返回目录 下一章 →