AirSim 接入 Gazebo 作为外部飞行动力学模型（FDM）的 GazeboDrone 实战指南-平芜编程栈

自动驾驶
人工智能
深度学习
强化学习
计算机视觉
科研

【免费下载链接】AirSim

Open source simulator for autonomous vehicles built on Unreal Engine / Unity, from Microsoft AI & Research

项目地址：https://gitcode.com/gh_mirrors/ai/AirSim

AirSim 官方仓库中的GazeboDrone示例提供了一条将 Gazebo 仿真环境接入 AirSim 的路径：让 Gazebo 承担飞行器动力学模型（Flight Dynamic Model, FDM）的角色，而 AirSim 负责渲染环境与输出传感器数据。本指南以 docs/gazebo_drone.md 为核心骨架，结合仓库中的源码与配置，完整讲解依赖安装、AirLib 与 UE 插件的编译差异、settings.json配置、CMake 构建以及最终运行流程，帮助你理解"外部物理引擎"模式的工作原理，并能独立复现这一混合仿真方案。

一、GazeboDrone 是什么：一种"双仿真器"协作架构

GazeboDrone 是 AirSim 仓库中的一个独立示例工程，其核心思路是分工协作：

Gazebo负责飞行器的动力学仿真，即计算飞行器在力和力矩作用下的运动响应；
AirSim负责生成环境视觉与传感器数据（如相机画面），并作为用户与无人机交互的接口。

这种架构意味着 Gazebo 中仿真的可以是多旋翼（Multicopters）、固定翼（Fixed-wings）或任何其他飞行器，只要能在 Gazebo 中建立模型，就能借助 AirSim 获得高质量的传感器仿真能力。其价值在于：你可以在不修改 AirSim 内部物理引擎的前提下，把第三方（尤其是带气动模型的固定翼）飞行器"塞进"AirSim 的传感器仿真框架中。

从代码层面看，GazeboDrone 是一个独立的可执行程序，其工程文件位于 GazeboDrone/：

GazeboDrone/CMakeLists.txt —— 构建脚本，负责链接 Gazebo 与 AirLib 库；
GazeboDrone/src/main.cpp —— 主程序，负责监听 Gazebo 位姿话题并将位姿写入 AirSim。

二、依赖安装：Gazebo 与 AirLib

2.1 Gazebo 开发依赖

GazeboDrone 编译时需要 Gazebo 的开发头文件与库，原文档要求在 Ubuntu 上安装 Gazebo 9 的开发包：

sudo apt-get install libgazebo9-dev

从 GazeboDrone/CMakeLists.txt 第 11 行的find_package(gazebo REQUIRED)可以看出，工程强依赖 Gazebo 的 CMake 配置，且链接了gazebo/transport（话题通信）与gazebo/msgs（消息类型）等组件。

2.2 AirLib：必须用 GCC 8 构建

GazeboDrone 工程在编译时链接的是 AirLib 的静态/共享库（CMakeLists.txt 中的target_link_libraries列出了AirLib与rpc），而 Gazebo 9 生态在 Ubuntu 上通常以 GCC 8 工具链编译，因此要求AirLib 也以 GCC 8 编译，否则链接阶段可能因 ABI 不一致而失败。

在原文档给出的 AirSim 根目录下执行：

./clean.sh ./setup.sh ./build.sh --gcc

./clean.sh清理上一次构建产物；
./setup.sh完成子模块初始化等准备工作；
./build.sh --gcc以 GCC 编译器构建 AirLib（--gcc是选择编译器工具链的关键选项）。

AirLib 构建完成后，产物会输出到 AirSim 根目录的build_release/output/lib目录——这正是 GazeboDrone/CMakeLists.txt 第 22 行link_directories(../../build_release/output/lib)所引用的路径，两者必须保持一致。

三、AirSim 模拟器：UE 插件需要另一份 clang 构建

这里有一个关键陷阱：AirLib 库和 AirSim 的 Unreal Engine 插件必须用不同的编译器构建。

GazeboDrone 链接的 AirLib 需要GCC 8（见上一节）；
而 AirSim 的 UE 插件（即运行在 Unreal 环境中的仿真器本体）需要clang编译（Unreal Engine 在 Linux 上默认使用其内置的 clang 工具链）。

因此，上一节用./build.sh --gcc编译出的 AirLib 不能直接用于 UE 插件。原文档给出的解决方案有两种：

使用官方预编译二进制：直接从 AirSim 的 Releases 页面下载编译好的仿真器与环境；
另建一份源码树：将 AirSim 仓库克隆到另一个目录，不添加--gcc选项重新构建，然后按 docs/build_linux.md 中的说明运行 Blocks 环境或你自己的 UE 工程。

这样最终你会得到两套互不干扰的产物：一套（GCC 8）供 GazeboDrone 链接，一套（clang）供 UE 插件加载。

3.1 配置 AirSim 使用外部物理引擎

无论用哪种方式获得 UE 仿真器，都需要在 AirSim 的settings.json中启用外部物理引擎模式。原文档明确指出，需要在配置中加入：

"PhysicsEngineName":"ExternalPhysicsEngine"

这个配置项在 docs/settings.md 中有更详细的解释：对多旋翼，AirSim 支持"FastPhysicsEngine"（默认内置物理引擎）和"ExternalPhysicsEngine"两种；后者允许通过simSetVehiclePose()接口控制无人机位姿——无人机在被下一次调用更新前会保持原位。这正是 GazeboDrone 的工作基础。

从源码看，AirLib/include/common/AirSimSettings.hpp 中该配置的读取逻辑为：未显式指定时，多旋翼模式默认使用FastPhysicsEngine，因此必须显式填写ExternalPhysicsEngine才能切换到外部引擎。同时注意，AirLib/include/physics/ExternalPhysicsEngine.hpp 的实现中update()只调用每个物理体的updateKinematics()与update()，自身不计算任何动力学——即所有运动状态都由外部程序喂入。

补充说明：根据 docs/settings.md 的描述，ExternalPhysicsEngine模式对小车无效（小车目前只支持 PhysX），GazeboDrone 面向的是多旋翼等飞行器。

此外，如果你希望 AirSim 中的无人机模型与 Gazebo 模型视觉上一致，原文档提示可以参考对应的视觉模型替换教程（替换 UE 中的飞行器模型）。

四、编译 GazeboDrone

在 AirSim 根目录下执行以下命令完成构建：

cd GazeboDrone mkdir build && cd build cmake -DCMAKE_C_COMPILER=gcc-8 -DCMAKE_CXX_COMPILER=g++-8 .. make

要点说明：

-DCMAKE_C_COMPILER=gcc-8 -DCMAKE_CXX_COMPILER=g++-8强制 CMake 使用 GCC 8 工具链，与 AirLib 的编译方式保持一致；
CMake 配置阶段会自动执行find_package(gazebo REQUIRED)，若找不到 Gazebo 会直接报错，请确认第一步的libgazebo9-dev已正确安装；
GazeboDrone/CMakeLists.txt 中设置了CMAKE_CXX_STANDARD 11，并将AirLib/deps/eigen3、AirLib/deps/rpclib/include、AirLib/include加入头文件搜索路径，链接目标是AirLib与rpc库——这些目录与库均来自第二步用 GCC 8 构建的 AirLib 产物。

编译成功后，build目录下会生成名为GazeboDrone的可执行文件。

五、运行：先启动两个仿真器，再启动 GazeboDrone

运行顺序非常关键，原文档要求：

先启动 AirSim 仿真器（UE 环境，如 Blocks 或你自己的工程）；
再启动 Gazebo中的无人机模型（如 Gazebo 自带的模型或自定义 SDF/URDF 模型）；
最后在 AirSim 根目录执行：

cd GazeboDrone/build ./GazeboDrone

5.1 程序内部做了什么

从 GazeboDrone/src/main.cpp 可以完整还原程序的执行流程：

连接 AirSim：创建msr::airlib::MultirotorRpcLibClient并调用client.confirmConnection()（第 114 行），与运行中的 AirSim RPC 服务握手；
初始化 Gazebo 客户端：调用gazebo::client::setup()启动 Gazebo 通信，创建 transport 节点（第 117-121 行）；
订阅两个话题（第 124-125 行）：
- ~/pose/local/info—— 订阅本地坐标系位姿，回调cbLocalPose；
- ~/pose/info—— 订阅全局坐标系位姿，回调cbGlobalPose；
位姿转发：cbLocalPose中把 Gazebo 报告的位姿做坐标系换算（p(x, y, -z)、o(ow, ox, -oy, -oz)，即将 Gazebo 的 Z 轴方向映射到 AirSim 的 NED 约定），然后调用client.simSetVehiclePose(Pose(p, o), true)写入 AirSim（第 70-75 行）——这正是 AirLib/include/api/RpcLibClientBase.hpp 中声明的simSetVehiclePose接口，第二个参数true表示忽略碰撞；
主循环：while (true) gazebo::common::Time::MSleep(10)（第 127-128 行）保持进程存活，并以约 100 条消息一次的频率（MESSAGE_THROTTLE = 100）在终端打印本地/全局位姿，便于观测。

也就是说，Gazebo 的动力学计算结果通过话题实时流入 AirSim，AirSim 中的无人机位姿被持续刷新，同时 AirSim 仍按自身逻辑渲染相机画面与传感器数据——这即是"Gazebo 提供 FDM、AirSim 提供环境传感器数据"的完整闭环。

5.2 坐标系换算的工程细节

注意cbLocalPose中的两个细节：位置直接取(x, -y, -z)，四元数取(ow, ox, -oy, -oz)。这是因为 Gazebo 使用 ENU（东-北-上，Z 轴向上）坐标系，而 AirSim 使用 NED（北-东-下，Z 轴向下）坐标系。若你自定义 Gazebo 模型，需要确认 Gazebo 输出的位姿约定与此映射一致，否则 AirSim 中无人机的姿态会出现镜像或翻转。

六、扩展思路与注意事项

更换飞行器类型：由于 AirSim 侧只是被动接收位姿，Gazebo 中无论是多旋翼还是固定翼模型，只要持续发布~/pose/local/info话题，即可被转发到 AirSim。固定翼研究者可以借此绕过 AirSim 内置的多旋翼物理引擎，直接使用 Gazebo 的气动模型。
多无人机：cbLocalPose遍历了msg->pose(i)中的所有位姿（对应 Gazebo 场景中多个模型），并只对索引 0 的模型调用simSetVehiclePose。若需多机联动，可以扩展为按名称匹配不同模型并分别设置不同车辆。
碰撞处理：simSetVehiclePose的ignore_collision参数在 GazeboDrone 中固定传true，即 AirSim 侧不进行碰撞响应——碰撞与避障逻辑需要由 Gazebo 或上层策略承担。
调试观测：程序在终端持续打印 Gazebo 上报的 local/global 位姿（位置 x/y/z 与四元数 ow/ox/oy/oz），可用于验证两个仿真器的位姿同步是否正常。

七、常见问题排查

现象	可能原因与排查方向
`cmake`报找不到 Gazebo	未安装`libgazebo9-dev`，或 Gazebo 版本与 CMake 配置不匹配
链接`AirLib`失败	AirLib 未用 GCC 8 构建，或`build_release/output/lib`下缺少库文件
启动后 AirSim 中无人机不动	`settings.json`未设置`"PhysicsEngineName":"ExternalPhysicsEngine"`，或未先启动 AirSim 仿真器
无人机位姿方向异常	Gazebo 模型坐标系与 ENU→NED 换算约定不一致

小结

GazeboDrone 展示了 AirSim 开放架构的典型用法：通过ExternalPhysicsEngine模式与 RPC 位姿注入接口，把第三方动力学仿真器无缝接入 AirSim 的传感器与环境仿真框架。整个链路中，docs/gazebo_drone.md 给出了从依赖安装到运行的完整步骤，而 GazeboDrone/src/main.cpp 与 AirLib/include/physics/ExternalPhysicsEngine.hpp 则揭示了其背后的实现原理。掌握了这条链路，你就可以在自己的项目中复现"Gazebo 动力学 + AirSim 传感器"的混合仿真方案。