ROS 2把机器人系统拆成可以通信、观察和替换的节点。它提供消息、工具和执行机制，具体的动力学、控制质量、时限和故障处理仍由系统设计决定。把所有函数放进多个节点，并不会自动得到实时或可靠的机器人。
先明确通信语义
| 接口 | 适合的数据 | 需要设计的行为 |
|---|---|---|
| topic | 图像、激光、里程计等持续数据流 | 频率、队列、时间戳、丢包与过期 |
| service | 有界的请求与响应，如查询参数 | 超时、失败返回、幂等性 |
| action | 导航、抓放等较长任务 | 目标ID、反馈、取消、抢占和最终结果 |
长时间运动不宜塞进一个阻塞service。取消请求被接收，也不代表机器人已经停稳；系统还需要确认执行状态和停止条件。相同topic名称只有消息类型、命名空间、域和QoS等条件匹配时才足以通信。
QoS不匹配可能导致一条消息都收不到
QoS包含可靠性、持久性、历史深度等策略。高频传感器可能更关心新数据而允许丢旧帧；配置和状态则可能要求迟加入的节点也能获得已发布内容。这里没有对所有topic通用的最佳配置。
例如best-effort发布者无法满足要求reliable的订阅者，反向的可靠性需求则可兼容。transient-local订阅者也不能要求volatile发布者保留历史。还应考虑其他策略组合，见ROS 2 Jazzy官方QoS文档源码。队列很深可能把延迟伪装成稳定吞吐，不适合直接用于实时反馈。
在已安装并加载相应ROS 2环境的终端中，可按顺序检查：
ros2 node list
ros2 topic list -t
ros2 topic info /scan --verbose
ros2 topic hz /scan
ros2 action list -t
这些排查命令未在本页的验证环境执行。hz观察到的接收频率也会受诊断订阅、网络和QoS影响，不能直接当作传感器硬件频率。
时间与TF要一起检查
仿真节点需要一致使用仿真时钟，相关节点的use_sim_time和/clock来源应一致。回放数据时还要检查时钟跳变、消息时间与TF缓存。TF2保存坐标变换关系，但按错误时刻查询，得到的数值仍可能不适合当前传感器观测。ROS 2时间设计解释系统时间、稳态时间和ROS时间的不同用途。
控制超时适合使用不受系统时间调整影响的单调时间；传感器间对齐需要共享时间语义。不要用消息到达当前进程的时间覆盖原始采样时间。
回调、生命周期与记录
订阅回调中等待另一个需要同一执行器处理的回调，可能形成死锁或饥饿。应明确executor、callback group及共享状态的并发规则。大模型推理、磁盘写入和复杂规划不宜阻塞高频控制数据通路；跨线程交接也要处理数据有效期。
受管理节点通过配置、激活、停用和清理等状态控制资源，减少“控制已启动但标定未加载”的启动竞态。具体客户端库的行为以实现为准；生命周期设计背景见官方设计文档。
rosbag记录应同时覆盖必要观测、TF、命令、反馈与参数版本，回放时检查QoS和时钟。只录最终路径通常不足以重现规划失败。
练习：列出导航任务所需的topic、action与坐标链，并写出“激光未到达、TF缺失、目标已取消”各自应该观察什么。面试自查：可靠传输是否等于按时到达？节点进程活着与任务可用有什么区别？