3. FlightGear核心概念与架构：场景图、属性树、FDM与协议系统
各位同学，大家好。今天我们来聊聊FlightGear的骨架——它的核心架构。说实话，我第一次接触FlightGear时，也被它庞大的代码库吓了一跳。但后来我发现，只要抓住四个核心概念，整个系统就清晰了：场景图(Scenegraph)、属性树(Property Tree)、飞行动力学模型(FDM)和协议系统(Protocol)。这四样东西，就像飞机的四个轮子，缺一个都跑不起来。
核心观点：FlightGear的架构设计，说白了就是「数据驱动」+「模块解耦」。属性树是全局数据总线，场景图管渲染，FDM管物理，协议管通信。各干各的，互不干扰。
3.1 场景图(Scenegraph)——渲染的骨架
场景图是什么？我打个比方。你想想看，一个3D场景里有飞机、有跑道、有树木、有建筑。如果每个物体都独立渲染，那性能会差到没法用。场景图就是把这些物体组织成一棵树，父节点变换了，子节点跟着变。
我个人习惯把场景图理解成「3D世界的DOM树」。每个节点代表一个物体或一组物体，节点之间是父子关系。比如：
- 根节点：整个场景
- 子节点：飞机模型、地面、天空
- 孙节点：飞机的机翼、引擎、起落架
我在项目中遇到过一个问题：飞机模型加载后，起落架的位置死活不对。查了半天，发现是场景图里起落架节点的父节点变换矩阵写错了。嗯，这里要注意——场景图的变换是累加的，父节点动一寸，子节点动一尺。
实战技巧：调试场景图时，可以用 --prop:/sim/scenegraph/debug=true 启动FlightGear，它会打印出场景图的树形结构。我每次做模型导入，第一件事就是开这个开关。
3.2 属性树(Property Tree)——系统的神经中枢
属性树，说白了就是FlightGear的「全局变量池」。所有模块——FDM、场景图、仪表、网络——都通过属性树读写数据。它是一个树形结构的键值对数据库，节点路径就像文件路径一样：/position/latitude-deg、/engines/engine[0]/rpm。
为什么用属性树？我刚开始也觉得多此一举。后来做飞控接入时才发现，没有属性树，各个模块之间就是一团乱麻。FDM算出的姿态数据，场景图要读，仪表要读，网络要发，如果没有统一的数据总线，你想想看，每个模块都得自己维护一套接口，那代码还能看吗？
属性树的核心操作就四个：
| 操作 | 命令 | 说明 |
|---|---|---|
| 读取 | props.getNode("/position/latitude-deg") |
获取节点对象 |
| 写入 | node.setDoubleValue(39.5) |
设置数值 |
| 监听 | node.addChangeListener(listener) |
值变化时触发回调 |
| 遍历 | node.getChildren() |
获取所有子节点 |
避坑指南：我曾经在属性树里写了一个死循环监听器——A节点变化时更新B，B节点变化时又更新A。结果FlightGear直接卡死。记住：监听器里不要修改触发它的节点，或者加一个防递归标志。
3.3 FDM(飞行动力学模型)——飞行的灵魂
FDM是FlightGear最核心的部分。它负责计算飞机在每一帧受到的力、力矩，然后更新位置和姿态。FlightGear内置了多种FDM：
- JSBSim：基于C++的通用FDM，支持自定义气动数据
- YASim：基于几何参数的FDM，配置简单
- UIUC：基于LaRC-SIM的FDM，学术研究用得多
- External：外部FDM，通过网络接口接入
我个人最常用的是JSBSim。为什么？因为它把气动数据写在XML文件里，改起来方便。我在做飞控接入时，需要把真实飞机的气动数据导入FlightGear，JSBSim的XML格式让我可以直接写脚本批量生成。
FDM的工作流程是这样的：
- 读取当前状态（速度、姿态、舵面位置）
- 计算气动力和力矩（升力、阻力、侧力、俯仰力矩等）
- 求解运动方程（牛顿第二定律 + 欧拉方程）
- 更新位置和姿态
- 写回属性树
嗯，这里要注意——FDM的更新频率和渲染频率是分开的。FDM通常跑120Hz，渲染只有60Hz。FlightGear会做插值，让画面看起来平滑。
关键点：做飞控接入时，你只需要关注属性树里的几个关键节点：/fdm/jsbsim/position、/fdm/jsbsim/attitude、/fdm/jsbsim/velocities。你的飞控数据写进去，FDM会自动接管物理计算。
3.4 协议系统(Protocol)——与外界的桥梁
协议系统，说白了就是FlightGear的「网络接口」。它支持多种协议，让外部程序可以读写属性树。常用的协议有：
| 协议 | 端口 | 用途 |
|---|---|---|
| Telnet | 5500 | 命令行交互，调试用 |
| HTTP | 5501 | Web界面控制 |
| Generic | 自定义 | UDP/TCP数据流，飞控接入首选 |
| MP | 5000 | 多机联网 |
我做飞控接入时，最常用的是Generic协议。它允许你自定义数据格式，比如：
# 协议配置文件 example.xml
<PropertyList>
<generic>
<input>
<line_separator>newline</line_separator>
<var_separator>,</var_separator>
<chunk>
<name>roll</name>
<type>float</type>
<node>/fdm/jsbsim/attitude/phi-rad</node>
</chunk>
<chunk>
<name>pitch</name>
<type>float</type>
<node>/fdm/jsbsim/attitude/theta-rad</node>
</chunk>
</input>
</generic>
</PropertyList>这样配置后，FlightGear就会在指定端口接收roll,pitch格式的数据，并自动写入属性树。你的飞控只需要按这个格式发UDP包就行。
实战技巧：调试协议时，我习惯先用 netcat 手动发数据测试。比如 echo "0.1,0.2" | nc -u localhost 5502，看看FlightGear有没有反应。这样能快速定位是协议配置问题还是飞控端问题。
好了，这四个核心概念讲完了。场景图管渲染，属性树管数据，FDM管物理，协议系统管通信。它们各司其职，又通过属性树紧密协作。你想想看，这种架构设计是不是很优雅？每个模块都可以独立替换——你想换FDM？改个配置就行。你想换渲染引擎？只要它读写属性树就行。
下一节，我们会动手搭建开发环境，把这些概念落地到代码里。到时候你就知道，理论懂了，实践起来其实没那么难。