4. ROS 核心概念：节点、话题、服务、参数服务器
好，咱们开始聊 ROS 里最核心的四个概念。说实话，我刚接触 ROS 那会儿，看了半天文档，脑子里还是一团浆糊。什么节点、话题、服务……感觉像一堆新名词在打架。后来自己动手搭了一个机械臂仿真，才慢慢摸清楚它们到底是怎么配合的。
你想想看，一个机械臂要动起来，得有多少东西在干活？电机要转、传感器要读数据、控制器要算角度、规划器要算路径……如果所有代码都写在一个程序里，那维护起来简直是噩梦。ROS 的思路很简单——把一个大系统拆成多个小模块，每个模块只干一件事，然后让它们互相通信。
这四个概念，就是这套通信机制的核心。咱们一个一个来拆。
4.1 节点（Node）—— 干活的最小单元
节点，说白了就是一个可执行程序。在 ROS 里，每个节点只负责一个具体的功能。比如：
/joint_state_publisher节点：负责发布机械臂每个关节的角度/robot_state_publisher节点：负责根据关节角度计算机器人各连杆的位置/move_group节点：负责运动规划
每个节点都是独立运行的进程。它们之间互不干扰，一个节点挂了，其他节点还能继续跑。我在做第一个机械臂仿真时，就遇到过 /joint_state_publisher 节点因为配置文件写错而崩溃，但 /rviz 显示节点还在，我盯着屏幕看了半天才反应过来——哦，是那个节点没起来。
4.2 话题（Topic）—— 异步通信的“广播站”
节点之间怎么传数据？最常用的方式就是话题。你可以把话题想象成一个广播频道。
- 发布者（Publisher）：往频道里发消息，不管有没有人听
- 订阅者（Subscriber）：收听频道，有新消息就处理
这种模式是异步的。发布者发完就走，订阅者收到就处理。两边不需要等对方。举个例子：
# 发布者：每隔 0.1 秒发布一次关节角度
rostopic pub /joint_states sensor_msgs/JointState "{...}" -r 10
# 订阅者：收到角度后更新机械臂模型
rostopic echo /joint_states为什么用话题？因为机械臂仿真里，很多数据是持续流式的。关节角度每时每刻都在变，传感器数据不断刷新。用话题这种“发布-订阅”模式，天然适合这种场景。
关键点： 话题是一对多的。一个发布者，可以有多个订阅者。比如 /joint_states 话题，/robot_state_publisher 在订阅，/rviz 也在订阅，各取所需。
4.3 服务（Service）—— 同步通信的“一问一答”
有些场景，光靠话题不够。比如你让机械臂抓一个杯子，你得先问：“当前夹爪位置在哪？”然后等它回答，再决定下一步动作。这种请求-响应模式，就是服务。
服务和话题最大的区别：
| 特性 | 话题（Topic） | 服务（Service） |
|---|---|---|
| 通信方式 | 异步（发布-订阅） | 同步（请求-响应） |
| 数据流向 | 单向流式 | 双向，一问一答 |
| 典型场景 | 传感器数据、状态更新 | 触发动作、查询状态 |
| 是否阻塞 | 不阻塞 | 客户端会等待响应 |
举个例子，你写一个服务端节点，提供查询当前关节角度的服务：
# 服务端（伪代码）
def get_joint_angles(req):
return JointAnglesResponse(angles=[0.1, 0.2, 0.3])
rospy.Service('get_joint_angles', JointAngles, get_joint_angles)
# 客户端调用
rospy.wait_for_service('get_joint_angles')
resp = get_joint_angles_client(EmptyRequest())
print(resp.angles)4.4 参数服务器（Parameter Server）—— 全局“黑板”
参数服务器，你可以把它理解成一个全局字典。所有节点都能往里面写数据，也能从里面读数据。它存的是配置参数，不是流式数据。
比如机械臂的关节限位、PID 参数、模型文件路径……这些不会频繁变化的东西，放在参数服务器里最合适。
# 设置参数
rosparam set /arm_controller/joint1_max_angle 3.14
# 读取参数（在 Python 节点里）
max_angle = rospy.get_param('/arm_controller/joint1_max_angle')参数服务器的好处是：你改一个参数，所有用到它的节点都能感知到。不用重启节点，不用改代码。我在调试机械臂轨迹时，经常一边跑仿真一边调 PID 参数，实时看效果，效率高很多。
4.5 它们怎么配合？一张图看懂
下面这张图，是我自己总结的 ROS 核心通信模型。你看一遍，基本就明白这四个概念是怎么串起来的了。
你看，节点 A 发布数据到话题，节点 B 和 C 订阅话题拿到数据。节点 C 需要确认某个状态时，通过服务向节点 B 发起请求。而所有节点都能从参数服务器读取全局配置。这套机制，把整个机械臂仿真系统拆得清清楚楚。
4.6 本章小结
四个概念，其实就对应了四种通信场景：
- 节点：谁在干活？—— 每个独立的功能模块
- 话题：持续广播数据 —— 适合传感器、状态流
- 服务：一问一答 —— 适合触发动作、查询
- 参数服务器：全局配置中心 —— 存参数，不改代码