2、ROS话题基础回顾：ROS话题通信机制、常用建图话题、话题频率与延迟概念
做SLAM这么多年，我见过太多人一上来就调参数、改代码，结果地图建出来歪七扭八。其实很多问题，根源都在ROS话题通信上。说白了，你连数据怎么传的、传得快不快都没搞清楚，怎么指望它建出好图？
这一节，咱们就把ROS话题通信的底裤扒一扒。嗯，别嫌基础，这些是排查建图异常的“内功心法”。
2.1 ROS话题通信机制：数据是怎么到你手里的？
ROS话题通信，本质上是一个发布/订阅模型。你可以把它想象成一个广播电台：
- 发布者（Publisher）：就是电台主持人，只管往外喊话（发布消息）。
- 订阅者（Subscriber）：就是听众，想听哪个频道就调过去（订阅话题）。
- 话题（Topic）：就是频道名称，比如 /scan、/odom。
这里有个关键点：发布者和订阅者完全解耦。主持人不知道谁在听，听众也不知道主持人长啥样。他们只认“频道名”和“消息类型”。
核心要点：ROS Master（名字服务节点）只负责牵线搭桥。一旦发布者和订阅者建立连接，数据就直接点对点传输了，Master就不再参与。所以，话题通信的实时性，完全取决于你的网络和节点处理能力。
我个人习惯在排查建图问题时，先用 rqt_graph 看一眼节点和话题的拓扑图。这招特别管用，能一眼看出谁在发、谁在收，有没有断连。
下面这张图，就是典型的建图系统话题通信结构：
小技巧：用 rostopic info /scan 可以查看话题的发布者和订阅者信息。如果发现“No publishers”或者“No subscribers”，那问题就找到了——数据根本没流通起来。
2.2 常用建图话题：你天天打交道的四个“老朋友”
建图系统里，有四个话题你几乎天天见。我一个个说，每个都踩过坑。
2.2.1 /scan —— 激光雷达数据
这是建图的“眼睛”。/scan 话题发布的是 sensor_msgs/LaserScan 消息，里面包含了一帧激光数据：
- angle_min / angle_max：扫描的起始和终止角度
- angle_increment：相邻两束激光的角度间隔
- range_min / range_max：有效测量距离范围
- ranges[]：距离数据数组
我记得有一次，同事说地图建出来全是“鬼影”。我一看，/scan 的 range_max 设成了 30 米，但实际雷达只能测 10 米。超出范围的数据全是 NaN，建图算法直接懵了。
避坑指南：我曾经在调试时发现 /scan 频率只有 5Hz，但建图算法要求 10Hz。结果地图建出来一卡一卡的。后来发现是雷达的串口波特率设低了。所以，拿到数据第一件事：rostopic hz /scan 看看频率对不对。
2.2.2 /odom —— 里程计数据
里程计是建图的“腿”，告诉机器人走了多远、转了多少角度。通常来自轮式编码器或IMU。消息类型是 nav_msgs/Odometry：
- pose.pose：位置和姿态（x, y, z, 四元数）
- twist.twist：线速度和角速度
这里有个坑：/odom 的坐标系是 odom 系，而 /tf 里发布的 odom→base_link 变换必须和 /odom 消息一致。如果不一致，建图算法就会“精神分裂”——一边听 /odom 说“我在A点”，一边看 /tf 说“我在B点”。
2.2.3 /tf —— 坐标变换树
/tf 是建图系统的“骨架”。它维护了所有坐标系之间的变换关系。建图最关心的是：
- odom → base_link：里程计推算的机器人位姿
- base_link → laser：激光雷达在机器人上的安装位置
- map → odom：建图算法发布的全局位姿修正（由SLAM节点发布）
我个人习惯用 tf_echo /map /base_link 来实时查看机器人在map系下的位姿。如果这个变换跳变或者不更新，那地图肯定建不好。
核心要点：/tf 的发布频率通常很高（100Hz），但建图算法只关心最新的一帧。所以 /tf 的延迟问题不大，但 不能丢帧。一旦某个变换缺失，整个TF树就断了，建图算法会直接报错。
2.2.4 /map —— 建图结果输出
这是建图算法的“答卷”。消息类型是 nav_msgs/OccupancyGrid：
- info.resolution：地图分辨率（米/像素）
- info.width / info.height：地图尺寸（像素）
- info.origin：地图原点在世界坐标系中的位置
- data[]：栅格数据（0=空闲, 100=占据, -1=未知）
/map 话题通常只在建图过程中定期发布（比如每5秒一次），或者在收到请求时发布。如果你发现 rostopic echo /map 一直没数据，那建图算法可能根本没跑起来。
2.3 话题频率与延迟：数据“快不快”决定了地图“好不好”
建图算法对数据的时间特性非常敏感。我见过太多人只盯着地图看，却忽略了数据流的“节奏”。
2.3.1 话题频率（Hz）
频率就是每秒发布多少帧数据。建图系统对频率有硬性要求：
| 话题 | 推荐频率 | 频率过低的影响 | 频率过高的影响 |
|---|---|---|---|
| /scan | 10-20 Hz | 地图稀疏、定位漂移 | CPU过载、数据冗余 |
| /odom | 50-100 Hz | 位姿估计滞后、地图扭曲 | 计算资源浪费 |
| /tf | 50-100 Hz | 坐标变换不连续、算法报错 | 无明显影响（但浪费带宽） |
| /map | 0.2-1 Hz | 地图更新慢 | 频繁更新导致卡顿 |
怎么查频率？用 rostopic hz /scan 就行。如果频率忽高忽低，那说明系统负载有问题，或者数据源不稳定。
2.3.2 话题延迟（Latency）
延迟是数据从发布到被订阅的时间差。建图算法里，延迟比频率更致命。
你想想看：激光雷达在t0时刻扫了一帧数据，但建图节点在t0+100ms才收到。这时候机器人已经往前走了半米，算法却拿半秒前的数据去匹配当前位置——地图不扭曲才怪。
查延迟用 rostopic delay /scan。正常延迟应该在几毫秒到十几毫秒。如果超过50ms，就要排查了：
- 是不是网络拥堵？（多机通信时常见）
- 是不是发布节点处理太慢？（比如雷达驱动CPU占用过高）
- 是不是订阅节点处理不过来？（比如建图算法计算量太大）
小技巧：我习惯在启动建图算法前，先跑一个 rostopic bw /scan 看看带宽占用。如果一帧激光数据有 10KB，10Hz 就是 100KB/s，这在千兆以太网下没问题，但在串口或WiFi下就可能成为瓶颈。
2.4 小结：排查建图异常，先从话题入手
好了，这一节的内容就这些。说白了，建图异常排查的第一步，就是确认数据流是否正常。我个人的排查顺序是：
- 查话题是否存在：
rostopic list看看 /scan、/odom、/tf 都在不在 - 查话题频率：
rostopic hz看看数据节奏对不对 - 查话题延迟：
rostopic delay看看数据是不是“过期货” - 查话题内容：
rostopic echo看看数据本身有没有异常
这套流程走下来，80%的建图问题都能定位到根因。剩下的20%，才是算法参数和硬件问题。