rqt_graph可视化：节点与话题关系图

调试复杂系统时，最让人头疼的是什么？

我个人觉得，是不知道数据到底流到哪去了。你启动了一堆节点，话题名也配了，但就是没反应。这时候，rqt_graph就是我的第一把救命工具。

说白了，它就是一张实时更新的系统架构图。节点是方框，话题是箭头。谁在发布，谁在订阅，一眼就能看穿。

命令很简单：

rqt_graph

或者从rqt的Plugins菜单里找到它。我习惯直接敲命令，快。

启动后你会看到一张图。别被密密麻麻的线吓到，它其实很有条理。

小技巧： 如果图太乱，勾掉"Hide Debug"和"Hide Leaf"选项。很多隐藏的中间节点会露出来，调试时特别有用。

每个椭圆或方框代表一个节点。每个箭头代表一个话题。箭头方向就是数据流动方向。

举个例子：

箭头从发布者指向订阅者。嗯，这里要注意：ROS2的箭头方向跟ROS1是反的。ROS1是从发布者指向订阅者，ROS2也是。但有些可视化工具会画反，我遇到过好几次，差点被带偏。

有一次，我在调试一个多机器人协作系统。6台机器人，每台有5个节点，话题总数超过40个。启动后系统卡死，但不知道哪里出了问题。

打开rqt_graph，我一眼就发现了一个循环依赖：

这就形成了一个闭环。数据在里面无限循环，CPU很快就跑满了。

避坑指南： 我曾经花了一整天排查一个死锁问题，最后发现是两个节点互相订阅了对方的话题。rqt_graph上两条箭头形成一个圆圈，非常明显。所以，每次启动新系统，我第一件事就是看rqt_graph，检查有没有循环。

系统大了，图就乱了。rqt_graph提供了几个过滤选项：

我常用的组合是：勾掉"Hide Leaf"，然后按Ctrl+F搜索特定节点名。这样只显示跟它相关的子图，调试效率高很多。

有一次，我发现/lidar_node发布的点云数据，/mapping_node收不到。但rqt_graph上明明有箭头连接。

我点开箭头，查看话题信息。发现/lidar_node发布的是sensor_msgs/PointCloud2，但/mapping_node订阅的是sensor_msgs/PointCloud。类型不匹配！

rqt_graph不会告诉你类型不匹配，但它会显示话题名。我对比了一下，发现话题名虽然一样，但类型不同。这就是问题所在。

  核心要点： rqt_graph显示的是连接关系，不是连接质量。箭头存在不代表数据能正常流通。类型匹配、QoS设置、网络延迟，这些都需要其他工具来检查。

下面这张图展示了rqt_graph的核心逻辑：从节点和话题的注册信息，生成可视化的关系图。

图是空的： 检查ROS_DOMAIN_ID是否一致。我遇到过两次，都是因为不同终端用了不同的domain ID。
节点显示不全： 试试用ros2 node list和ros2 topic list确认节点是否真的在运行。有时候rqt_graph刷新不及时，手动点一下"Refresh"按钮。
箭头太多看不清： 用"Nodes/Topics"模式，只看节点。或者用"Topic Type"过滤，只显示你关心的消息类型。

我的习惯： 每次启动新系统，我都会先跑rqt_graph，截一张图保存。等系统出问题时，对比截图，能快速发现新增的异常连接。这招帮我省了不少排查时间。

rqt_graph不是万能的。它看不到QoS设置，看不到消息内容，也看不到网络延迟。但它能给你一张地图。在复杂系统里，地图比什么都重要。