ROS话题详解：发布-订阅机制原理与实战调试

1. 什么是ROS话题：从“快递站”到“数据高速公路”的真实理解

刚接触ROS时，我盯着turtlesim里那只慢悠悠转圈的乌龟，心里直犯嘀咕：这玩意儿到底怎么动起来的？键盘一按，它就走；松开手，它就停。背后没有一根线连着，也没有人实时盯着它发号施令——那指令到底是怎么“飞”过去的？后来我才明白，真正撑起整个ROS系统骨架的，不是节点，不是参数，更不是服务，而是话题（Topic）。它不像服务那样需要你“敲门问一声再进门”，也不像参数服务器那样只存个静态值；它是一条永不停歇的数据高速公路，是ROS里最基础、最常用、也最容易被新手误解的通信机制。

说白了，ROS话题就是一种发布-订阅（Publish-Subscribe）模型的具体实现。你可以把它想象成一个城市里的快递中转站：turtle_teleop_key不是直接把包裹（控制指令）塞进turtlesim_node的手里，而是把包裹打包好，贴上标签“/turtle1/cmd_vel”，扔进中转站的传送带；而turtlesim_node则在同一个中转站里设了个固定取件点，只要标签匹配，传送带一过来，它就自动取走、拆包、执行。这个“中转站”就是ROS Master（由roscore启动），它不参与数据内容，只负责登记谁在发、谁在收、发的是什么类型——就像快递站管理员只管登记运单号和收发点，不管里面装的是螺丝刀还是咖啡豆。

为什么非得用这种“绕一圈”的方式？因为解耦。我当年在做AGV小车项目时踩过坑：最初把传感器数据处理和运动控制写在一个进程里，结果激光雷达一卡，小车轮子就跟着卡顿。后来拆成独立节点，用话题通信，哪怕视觉节点崩溃了，底盘控制还能靠IMU数据继续跑。这就是话题的核心价值——让系统模块之间彼此“不认识”，却能高效协作。它天然支持一对多（一个发布者，多个订阅者）、多对一（多个发布者，一个订阅者），甚至多对多。比如你同时启动两个遥控节点，它们都能往/cmd_vel发指令，而底盘控制器只认最新一条——这种灵活性，是硬连线或RPC调用根本做不到的。

关键词“ros话题”绝不是个抽象概念，它是你每天调试ROS系统时最先打交道的实体。rostopic list是你打开系统的第一扇窗，rostopic echo是你听诊器，rostopic pub是你临时打补丁的扳手。它不炫酷，不复杂，但如果你没真正搞懂它背后的发布-订阅逻辑、消息类型约束、频率特性，后面学服务、动作、参数，全都会像建在沙地上的楼。所以别急着往后翻，先把这个“快递中转站”摸透。接下来我会带你一层层剥开它的外壳，从底层原理到实操细节，再到那些只有踩过坑才懂的经验。

2. 话题通信的底层逻辑与设计哲学

2.1 发布-订阅模型为何成为ROS的基石？

ROS选择发布-订阅模型，不是拍脑袋决定的，而是被机器人系统的真实需求倒逼出来的。我带过三届ROS实训班，每次讲到这儿，我都会让学生关掉所有终端，只留roscore，然后问：“如果现在要加一个新功能——比如让乌龟画个圆，但又不能改turtlesim_node源码，你怎么干？”90%的人第一反应是去改代码。但真正的ROS思维是：我不动原节点，只加一个新节点，让它往同一个话题发消息就行。

这就是发布-订阅的威力——它把“谁来提供数据”和“谁来使用数据”彻底分开。turtlesim_node只关心“我该听哪个话题”，它根本不care是谁在发；turtle_teleop_key只管“我把指令发到哪”，它也不care谁在收。这种松耦合带来三个硬核优势：

第一，可替换性。去年我们给某高校实验室升级导航系统，原激光雷达驱动节点用的是ROS 1的urg_node，新采购的雷达厂商只提供ROS 2的驱动。怎么办？我们没动SLAM节点和路径规划节点，只写了个轻量级桥接节点，把ROS 2的/scan话题转换成ROS 1的/scan话题，中间用topic_tools relay转发。整个过程，下游节点毫无感知——因为它们只认话题名和消息类型，不认发布者ID。

第二，可观察性。你在调试时，永远可以随时插一个rostopic echo进去“偷听”数据流，而不会干扰原有通信。这就像在水管上装个透明观察窗，不用关闸就能看到水流。对比服务调用，你没法在/add_two_ints服务调用中途截获请求参数——服务是点对点的、有状态的、一次性的；而话题是广播式的、无状态的、持续的。

第三，弹性伸缩。一个/tf话题可以同时被导航节点、可视化节点、记录节点、仿真节点订阅。你加一个新节点，只要它订阅/tf，立刻就能拿到所有坐标变换数据；删掉一个节点，其他节点照常运行。这种“即插即用”的能力，在分布式机器人系统里是刚需——想想一个由10台机器人组成的集群，每台都要广播自身位姿，如果用服务调用，光建立连接就要耗掉大半CPU。

提示：发布-订阅不是万能的。它不适合需要强响应保证的场景。比如你发一条“紧急停止”指令，必须确保底盘控制器100%收到并立即执行。这时候话题就不够可靠——万一网络抖动丢了一帧呢？ROS提供了latched topic（粘性话题）来缓解，但真正保险的做法是配合服务调用或自定义心跳机制。这是新手最容易混淆的边界。

2.2 话题名、消息类型、序列化：三位一体的通信契约

ROS话题通信的可靠性，建立在一套严格的“契约”之上。这个契约由三要素构成：话题名（Topic Name）、消息类型（Message Type）、序列化格式（Serialization Format）。缺一不可，少一个就会报错。

• 话题名：是字符串标识符，必须全局唯一。它不是路径，而是命名空间。/turtle1/cmd_vel中的斜杠只是分隔符，turtle1和cmd_vel都是名字的一部分。我见过太多人误以为/turtle1/cmd_vel和/turtle2/cmd_vel是父子关系，其实它们是完全独立的两个话题，就像/car/brake和/bike/brake互不影响。ROS Master内部用哈希表管理这些名字，查找效率O(1)。

• 消息类型：这才是真正的“合同条款”。geometry_msgs/Twist这个类型，明确定义了消息必须包含linear和angular两个字段，每个字段又必须是Vector3类型，而Vector3又规定了x/y/z三个float64成员。这种嵌套定义通过.msg文件实现，编译时生成对应语言的类（C++的Twist.h，Python的Twist.py）。发布者和订阅者必须使用完全相同的消息类型定义，否则ROS Master会拒绝注册。这也是为什么rostopic type /turtle1/cmd_vel返回geometry_msgs/Twist后，你必须用rosmsg show geometry_msgs/Twist确认结构——它不是告诉你“大概长这样”，而是告诉你“必须长这样”。

• 序列化格式：ROS默认用ROS Serialization（基于Google Protocol Buffers思想定制），把内存中的对象转换成字节流在网络上传输。关键点在于：序列化是语言无关的，但必须版本一致。ROS 1的std_msgs/String和ROS 2的std_msgs/msg/String虽然名字一样，但序列化协议不同，不能互通。这也是为什么ROS 1和ROS 2需要专门的ros1_bridge来转换话题数据——它本质是个序列化格式翻译器。

我当年在调试一个跨平台机械臂时，发现PC端Python节点能收到数据，但嵌入式ARM端C++节点收不到。查了两小时，最后发现是ARM交叉编译环境里rosidl_generator_c版本比PC端低一级，导致JointState消息的内存布局偏移量不一致，反序列化时直接段错误。这种底层细节，文档里往往一笔带过，但实操中就是拦路虎。

2.3 话题生命周期与Master的角色：那个不说话的调度员

很多人以为roscore是数据中转站，其实大错特错。roscore启动后，核心组件是rosout（日志）、parameter server（参数服务器）和ROS Master。而Master本身不传输任何用户数据，它只干三件事：

1. 注册管理：当turtle_teleop_key启动时，它向Master发送注册请求：“我要发布话题/turtle1/cmd_vel，类型是geometry_msgs/Twist”；当turtlesim_node启动时，它发请求：“我要订阅话题/turtle1/cmd_vel”。Master把这两个请求记在内存表里，形成映射关系。

2. 节点发现：当发布者和订阅者都注册完成后，Master会把对方的TCP/IP地址和端口告诉彼此。这时，turtle_teleop_key才知道turtlesim_node监听在192.168.1.100:45678，而turtlesim_node也知道发布者在192.168.1.100:12345。后续所有数据通信，都是发布者和订阅者直接TCP连接，Master全程不参与。

3. 状态维护：Master定期检查注册节点是否存活（通过心跳包）。如果某个节点崩溃，Master会通知所有相关方，并从映射表中删除它。这就是为什么你Ctrl+C停掉turtle_teleop_key后，rostopic list里立刻看不到/turtle1/cmd_vel的发布者了——不是话题消失了，而是发布者下线了，Master更新了状态。

注意：Master不保证消息送达。它不缓存数据，不重传丢包，不排序乱序。如果你发100条Twist消息，订阅者可能收到98条、102条（重复），或者顺序错乱。这是设计使然——ROS优先保证实时性而非可靠性。需要可靠传输？得自己加应用层逻辑，比如在消息里加序列号、用服务确认、或换DDS中间件（ROS 2默认）。

3. 核心工具链深度解析：rostopic与rqt_graph的实战用法

3.1 rostopic：不只是命令，是ROS系统的听诊器和手术刀

rostopic系列命令看似简单，但每个子命令背后都有明确的设计意图和适用场景。我把它比作一套精密的医疗器械：list是X光机，echo是内窥镜，pub是注射器，hz是心电图仪。用错工具，轻则白忙活，重则误判病情。

rostopic list：系统健康快检

rostopic list是诊断第一步。但新手常犯的错是只用rostopic list，不加参数。这就像只看体检报告的“总览”，不看具体指标。真正有用的组合是：

# 查看所有活跃话题（最常用） rostopic list # 显示详细信息：谁在发、谁在收、消息类型（必用！） rostopic list -v # 只看发布者（排查数据源） rostopic list -p # 只看订阅者（排查数据去向） rostopic list -s

-v输出里藏着关键线索。比如你看到：

Published topics: * /turtle1/cmd_vel [geometry_msgs/Twist] 1 publisher * /turtle1/pose [turtlesim/Pose] 1 publisher Subscribed topics: * /turtle1/cmd_vel [geometry_msgs/Twist] 1 subscriber

这说明/turtle1/cmd_vel话题目前只有一个发布者、一个订阅者。如果某天你加了一个新节点订阅它，但rostopic list -v里没显示新增的订阅者，那问题一定出在新节点没成功注册——可能是节点名冲突、话题名拼错、或ROS_MASTER_URI没设对。这是我排查80%通信故障的第一步。

rostopic echo：实时数据监听与结构验证

rostopic echo是调试时用得最多、也最容易误用的命令。常见误区有三个：

误区一：不确认话题是否存在就盲echo
rostopic echo /nonexistent/topic不会报错，而是静静等待——因为它假设话题稍后会出现。结果你等半天没输出，以为系统卡了。正确姿势是先rostopic list | grep cmd_vel确认话题存在。

误区二：忽略消息结构差异导致解析失败
ROS Hydro前用turtlesim/Velocity（两个float），Hydro后用geometry_msgs/Twist（嵌套结构）。如果你在Hydro+系统里还用rostopic echo /turtle1/cmd_vel，看到的是：

linear: x: 2.0 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.0

而旧教程里写的rostopic echo /turtle1/command_velocity输出是linear: 2.0 angular: 0.0。这不是bug，是消息定义升级。永远用rostopic type确认当前话题的真实类型，再决定如何解析。

误区三：不加限制导致终端刷屏
rostopic echo /turtle1/pose会持续输出乌龟位姿，每秒60条，很快刷屏。实用技巧：

# 只看前5条（快速确认结构） rostopic echo /turtle1/pose -n 5 # 每2秒输出一条（降低刷新率） rostopic echo /turtle1/pose -p 2 # 输出到文件供离线分析（重要！） rostopic echo /turtle1/pose > pose_log.txt

rostopic pub：手动注入数据的精准手术

rostopic pub是调试神器，但参数语法堪称ROS里最反人类的设计。核心难点在YAML格式和参数解析器的博弈。

以发布Twist消息为例：

# 正确（Hydro+） rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, 1.8]' # 错误写法（会报错：invalid literal for float()） rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -- '2.0 0.0 0.0' '0.0 0.0 1.8'

为什么必须加单引号？因为Bash会把空格当参数分隔符。'[2.0, 0.0, 0.0]'作为一个整体传给rostopic，它再交给YAML解析器；而2.0 0.0 0.0会被Bash切成三个独立参数，rostopic收不到完整数组。

更隐蔽的坑是负数：

# 这会报错：unrecognized arguments: -1.8 rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, -1.8]' # 正确：用双引号包裹，或加空格避让 rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -- "[2.0, 0.0, 0.0]" "[0.0, 0.0, -1.8]" # 或 rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, -1.8]'

实操心得：我写了个速查表贴在显示器边（已验证ROS Noetic）：

3.2 rqt_graph：可视化系统拓扑的动态透视镜

rqt_graph不是简单的节点连线图，它是理解ROS系统架构的“上帝视角”。但很多人只把它当装饰，没挖出深层价值。

动态刷新与过滤技巧

默认rqt_graph显示所有节点和话题，大型系统里密密麻麻全是线。我的工作流是：

1. 启动时勾选“Hide Debug”：隐藏/rosout、/rosout_agg等调试话题，聚焦业务流。
2. 用搜索框过滤：输入cmd_vel，图中只高亮相关节点和话题。
3. 右键节点→“Show all connections”：查看该节点所有收发关系，比全局图清晰十倍。

从图中读出系统健康度

rqt_graph里藏着系统状态密码：

• 红色虚线箭头：表示话题未被任何节点订阅。比如你看到/sensor/camera/image_raw有发布者但没订阅者，说明图像处理节点没启动，或者话题名拼错了（image_rawvsimage）。
• 蓝色节点无连线：节点注册了，但没发布也没订阅任何话题——它可能卡在初始化，或根本没调用advertise()/subscribe()。
• 绿色节点悬空：节点只订阅不发布，可能是纯监控节点，也可能是发布逻辑没触发。

我调试一个无人机视觉导航系统时，发现rqt_graph里/mavros/local_position/pose话题只有发布者（PX4固件），没有订阅者。查代码发现视觉节点订阅的是/mavros/vision_pose/pose——名字差一个词，图上一眼就暴露。

提示：rqt_graph依赖rosnode info获取节点详情，如果节点通信异常，图可能延迟更新。遇到“明明节点在跑，图上却不显示”，先rosnode list确认节点存活，再rosnode ping <node_name>测连通性。

4. 实操全流程：从零搭建话题通信闭环并深度验证

4.1 环境准备与最小可行系统构建

别跳过这一步。我见过太多人直接复制粘贴命令，结果卡在roscore启动失败。以下是经过Noetic（Ubuntu 20.04）实测的完整流程，每一步都标注了验证方法：

步骤1：启动ROS Master（roscore）

# 新终端，启动核心 roscore

验证：终端输出应包含started core service [/rosout]，且光标停留在新行。如果报错roscore cannot run as another roscore/master is already running，说明已有roscore在后台运行。用ps aux | grep roscore查进程，kill -9 <PID>结束，或直接pkill roscore。

步骤2：启动turtlesim仿真器

# 新终端，启动乌龟仿真 rosrun turtlesim turtlesim_node

验证：弹出GUI窗口，显示蓝色背景和一只绿色乌龟。终端输出[INFO] ... Started node [/turtlesim]。如果窗口不出现，检查DISPLAY环境变量：echo $DISPLAY应为:0或localhost:10.0，否则export DISPLAY=:0。

步骤3：启动键盘控制节点

# 新终端，启动遥控 rosrun turtlesim turtle_teleop_key

验证：终端显示Reading from keyboard和操作提示。关键操作：必须用鼠标点击此终端窗口，使其获得焦点（Linux终端需主动获取输入权），否则按键无效。按方向键，乌龟应移动。

注意：如果乌龟不动，90%是终端没获得焦点。不要怀疑代码，先Alt+Tab切回该终端，再试。

此时系统已形成最小闭环：turtle_teleop_key→/turtle1/cmd_vel→turtlesim_node。但你还看不到数据流，下一步用工具“看见”它。

4.2 数据流观测：用rostopic和rqt_graph交叉验证

观测1：确认话题存在与类型

# 终端A：列出所有话题 rostopic list # 终端B：查看/turtle1/cmd_vel的详细信息 rostopic list -v | grep cmd_vel # 应输出：* /turtle1/cmd_vel [geometry_msgs/Twist] 1 publisher 1 subscriber # 终端C：确认消息类型 rostopic type /turtle1/cmd_vel # 应输出：geometry_msgs/Twist # 终端D：查看消息结构 rosmsg show geometry_msgs/Twist

观测2：实时监听控制指令

# 终端E：监听/cmd_vel（按↑键时应有输出） rostopic echo /turtle1/cmd_vel -n 3

预期输出（按↑键3次）：

linear: x: 2.0 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.0 --- linear: x: 2.0 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.0 --- ...

观测3：动态图谱可视化

# 终端F：启动rqt_graph rosrun rqt_graph rqt_graph

操作：

• 勾选左下角Hide Debug。
• 在搜索框输入cmd_vel。
• 将鼠标悬停在/turtle1/cmd_vel话题上，观察turtle_teleop_key（蓝色）和turtlesim_node（绿色）高亮，连线变粗。

此时你已用三种独立工具（列表、监听、图形）验证了同一数据流，可信度拉满。

4.3 主动干预：用rostopic pub替代键盘控制

这是理解话题本质的关键一步——亲手当一回“发布者”。

场景1：单次指令让乌龟转圈

# 终端G：发布一次旋转指令（线速度0，角速度1.8） rostopic pub -1 /turtle1/cmd_vel geometry_msgs/Twist -- '[0.0, 0.0, 0.0]' '[0.0, 0.0, 1.8]'

现象：乌龟原地顺时针旋转约1秒后停止。因为只发了一条消息，turtlesim_node收到后执行，但无后续指令，自动归零。

场景2：持续指令维持运动

# 终端H：以1Hz频率持续发布前进指令 rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -r 1 -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, 0.0]'

现象：乌龟匀速直线前进。打开rqt_graph，你会看到新出现一个红色节点rostopic_XXXX（发布者），它和turtlesim_node之间有红色连线。

场景3：混合指令画圆

# 终端I：线速度2.0，角速度0.5，画大圆 rostopic pub /turtle1/cmd_vel geometry_msgs/Twist -r 10 -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, 0.5]'

现象：乌龟沿圆形轨迹运动。注意-r 10是10Hz，比1Hz更平滑。如果画出来是多边形，说明频率太低，增加-r值。

实操心得：rostopic pub的-r参数不是越高越好。turtlesim_node内部有最大处理频率（约60Hz），超过它只是徒增CPU占用。我测试过，-r 20和-r 60对乌龟轨迹肉眼无差别，但后者CPU占用高3倍。合理设置发布频率，是ROS系统优化的基本功。

4.4 高级验证：用rostopic hz和rqt_plot量化分析

验证1：测量话题发布频率

# 终端J：测量乌龟位姿发布频率 rostopic hz /turtle1/pose

输出解读：

subscribed to [/turtle1/pose] average rate: 59.354 # 平均59.354Hz min: 0.005s # 最短间隔5ms（对应200Hz） max: 0.027s # 最长间隔27ms（对应37Hz） std dev: 0.00284s # 波动很小，系统稳定 window: 58 # 当前统计了58个样本

这证明turtlesim_node以接近60Hz的稳定频率发布位姿，符合实时控制要求。

验证2：可视化数据变化趋势

# 终端K：启动rqt_plot rosrun rqt_plot rqt_plot

操作：

• 在左上角文本框输入/turtle1/pose/x，点+按钮添加。
• 输入/turtle1/pose/y，再点+。
• 图形区将显示X-Y坐标轨迹（应为圆形或直线）。
• 点-按钮，选择/turtle1/pose/x隐藏，再添加/turtle1/pose/theta，观察朝向角变化。

关键洞察：rqt_plot不是简单画图，它是时间序列分析工具。当你看到/turtle1/pose/theta曲线是平滑上升的直线，说明乌龟在匀速旋转；如果是锯齿状，说明控制指令有抖动。这比肉眼观察乌龟运动更精确。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 话题“消失”了？——订阅者不显示的5种真相

rostopic list -v里看不到某个话题的订阅者，是最常见的“灵异事件”。根据我处理过的200+案例，原因如下表：

真实案例：某学员的SLAM节点死活收不到/scan数据。rostopic list显示/scan有发布者，但无订阅者。查rosnode list发现SLAM节点在运行，rosnode info /slam_node却显示Subscriptions: None。最后发现他订阅时写了nh.subscribe("/scan ", 10, callback)——末尾多了个空格！ROS话题名/scan和/scan是两个不同话题。这种低级错误，rqt_graph上根本看不出来，只能靠rostopic list逐字比对。

5.2 rostopic echo“没输出”？——数据流中断的7层诊断法

当rostopic echo /topic静默无声，按以下顺序排查（我称之为“七层地狱”）：

1. 物理层：ping发布者节点所在主机，确认网络连通。
2. ROS层：rosnode list看发布者节点是否在列表中。
3. 注册层：rostopic list \| grep topic确认话题存在。
4. 类型层：rostopic type /topic确认类型正确，rosmsg show确认结构。
5. 发布层：rostopic hz /topic看是否有发布者（若hz也无输出，则发布者没发）。
6. 权限层：rosnode info <publisher_node>看其Publications是否包含该话题。
7. 数据层：用rostopic pub手动发一条，看订阅者是否响应（排除订阅者逻辑问题）。

独家技巧：在发布者节点代码中，加一行ROS_INFO_STREAM("Publishing: " << msg);，确认它真在发。我曾帮一个团队定位问题，发现他们的激光雷达驱动节点因硬件超时，悄悄跳过了publish()调用，但节点本身没崩溃——rostopic list一切正常，唯独echo没数据。加日志后秒定位。

5.3 rqt_graph“不更新”？——动态图谱失效的3个元凶

rqt_graph卡在旧状态，不随节点启停变化，通常因为：

• ROS Master通信异常：rqt_graph通过XML-RPC与Master通信，如果Master负载高或网络延迟，会超时。解决方案：重启rqt_graph，或rosnode kill /rqt_graph后重开。
• 节点未正确关闭：Ctrl+C有时不能优雅终止节点，残留进程仍注册在Master。用rosnode list查，rosnode cleanup清理。
• rqt插件缓存：rqt有内部缓存。关闭rqt_graph，执行rqt --clear-config清空配置，再重开。

终极手段：如果以上都无效，直接用命令行工具替代。rosnode list+rostopic list+rosnode info <node>组合，比图形界面更可靠。毕竟，ROS的本质是命令行工具链，图形只是锦上添花。

5.4 消息类型混乱？——跨ROS版本迁移的兼容性陷阱

ROS版本升级（如Kinetic→Melodic→Noetic）时，消息类型变更最让人头疼。典型案例如下：

迁移策略：

• 短期：用topic_tools transform做运行时转换。例如将旧Velocity转为新Twist：

  rosrun topic_tools transform /old_cmd_vel /cmd_vel geometry_msgs/Twist 'geometry_msgs.Twist(linear=geometry_msgs.Vector3(x=m.linear, y=0, z=0), angular=geometry_msgs.Vector3(x=0, y=0, z=m.angular))'

• 长期：重构代码，统一使用geometry_msgs/Twist。所有新项目必须以此为标准。

注意：rostopic type返回的类型名，必须和rosmsg show输出的完全一致。我见过有人把geometry_msgs/Twist写成geometry_msgs::Twist（C++风格），导致rostopic pub报错。ROS命令行只认/分隔的字符串。

6. 从话题到系统：构建可扩展的ROS通信架构

6.1 话题命名规范：让系统自解释的5条军规

一个设计良好的ROS系统，话题名应该像路标一样清晰。我在工业项目中推行的命名规范：

1. 前缀统一：所有机器人相关话题加/<robot_name>/前缀。如/agv01/cmd_vel、/arm02/joint_states。避免裸名/cmd_vel，防止多机器人冲突。
2. 语义明确：用动名词描述数据内容，而非来源。/camera/color/image_raw（原始图像）优于/usb_cam/image