第2章 · 系统架构与核心底层机制
第2章 · 系统架构与核心底层机制
本章要回答的三个问题：gz-sim 的服务器和客户端各自在干什么，为什么无头模式连显示器都不需要？仿真时间、墙钟时间、实时因子之间的账怎么算，传感器和控制器的更新为什么必须挂在仿真时钟上？"插件"到底是什么，为什么它能把仿真改造成任意形态而不用改 Gazebo 源码？
为什么会有这一章
第 1 章说 Gazebo 是"记账装置"。这一章拆开记账机器的外壳，看齿轮怎么咬合。不夸张地说，仿真排障问题的一大半是架构问题：机器人不动，是命令没到达还是插件没加载？传感器数据时间戳跳变，是渲染掉帧还是时钟没同步？云容器里起不来仿真，是缺 X11 还是起错了进程角色？这些问题的答案都在本章三节里。
另一个动机：gz-sim 的 ECS（实体-组件-系统）架构是它区别于 Classic 的根本。理解"世界由实体和组件构成、系统在每个迭代里按需读写组件"，你才能读懂它的日志、它的性能行为、它报错时的措辞。
读完能解决什么
- 能画出一次
gz sim启动后进程内的执行流，说出每个系统的职责边界； - 能诊断 RTF 掉到 0.3 的常见原因并按优先级排查；
- 能写出一个最小可用的世界插件，并知道该选哪个插件基类。
各节怎么分工
| 节 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 2.1 进程模型与组件通信 | 进程与系统怎么分工 | 服务器/客户端架构图 + 主题清单 |
| 2.2 仿真时钟与同步机制 | 时间账怎么对齐 | RTF 公式 + 时间源对照表 + 排障流程 |
| 2.3 插件系统 | 行为从哪里注入 | 插件类型对照 + 最小插件代码 |
章内概念关系
服务器是唯一的"真值持有者"，GUI 与你的节点都只是订阅者——这是 2.1 的核心；图里的"每步更新"如何与三种时间对齐是 2.2 的核心；往这条流水线里插入自定义行为的钩子就是 2.3 的主题。
先决条件
最好已经跑通过一次 gz-sim（哪怕只是 gz sim shapes.sdf），见过 GUI 长什么样。2.3 节的插件代码需要 C++ 编译环境，但只读不编译也能理解结构。
往下走到哪
本章讲的是"机器怎么转"；第 3 章钻进其中最重的一个齿轮——物理系统，把刚体、惯性、接触这些"硬账"的记账规则逐一核对。
一页排障地图：本章知识的组合拳
三节内容在真实排障里几乎总是组合出手，这里给一条可以直接贴在工位的排查主线。"机器人不动"走进程线：gz topic -e -t /model/*/cmd_vel 确认命令到达（2.1 的总线视角）→ 检查世界里的系统插件是否真的加载（服务端启动日志搜 gz-sim-*-system）→ 再怀疑物理。"数据时间戳乱"走时钟线：核对所有节点的 use_sim_time → gz topic -e -t /clock 确认仿真时间单调 → 对照传感器 <update_rate> 与控制器周期是否错配（2.2）。"整体卡顿"走性能线：-s 无头复跑分渲染账与物理账 → gz stats 落盘 RTF 曲线找首次掉速时刻（2.2）→ 对照场景事件定位到具体系统（2.1 的 ECS 审计视角）。三条线共用一个习惯：先看总线上有什么、再看哪段时间账不对、最后才进系统内部——顺序反了，排障时间翻倍。