CARLA-Air：空地协同具身智能的统一仿真基础设施 CARLA-Air: Fly Drones Inside a CARLA World -- A Unified Infrastructure for Air-Ground Embodied Intelligence
整合CARLA与AirSim于单一UE4进程，实现高保真空地联合仿真，支持18种传感器模态同步采集
前置知识
Unreal Engine 4 (UE4)
Epic Games开发的游戏引擎，采用C++编写，支持蓝图可视化编程。UE4的核心架构包括World（世界）、Actor（演员）、GameMode（游戏模式）等概念。每个World只能有一个活动的GameMode，该模式管理游戏的初始化、规则和生命周期。UE4的渲染管线基于PBR（基于物理的渲染），支持高质量的光照、阴影和后处理效果。CARLA和AirSim都基于UE4构建，利用其物理引擎Chaos Physics和渲染能力来创建逼真的仿真环境。
本文的核心技术挑战正是解决UE4的单GameMode约束问题。只有理解UE4的架构限制（每个世界只能有一个活动GameMode），才能理解为什么不能简单地将CARLA和AirSim的GameMode都加载到同一个世界中，从而理解作者提出的组合式解决方案的价值。
ROS 2 (Robot Operating System 2)
用于机器人应用开发的中间件框架，提供节点间通信机制（发布/订阅、服务、动作）、参数服务器、生命周期管理等核心功能。ROS 2基于DDS（数据分发服务）实现底层通信，支持实时性、可靠性和跨平台部署。在机器人仿真中，ROS 2常用于连接仿真器与控制算法、感知处理和决策规划模块。节点可以通过话题（topic）发布传感器数据，订阅控制命令，实现模块化架构。
本文对比了基于ROS 2的桥接式共仿真方案与CARLA-Air的单进程方案。理解ROS 2的通信机制有助于理解桥接方案引入的跨进程序列化开销和同步复杂度，以及为什么单进程架构能够消除这些开销。同时，CARLA-Air保留了ROS 2接口，支持63个话题的发布。
NED坐标系（North-East-Down）
航空航天领域广泛使用的右手坐标系，原点通常设在参考位置（如无人机起飞点）。X轴指向正北，Y轴指向正东，Z轴指向下方（垂直于参考椭球面）。NED坐标系的优点是与导航坐标系对齐，方便计算航向角和轨迹规划。在无人机控制中，NED坐标系常用于表示位置、速度和姿态。姿态表示通常使用四元数或欧拉角（偏航、俯仰、滚转）。
CARLA使用左手坐标系（X向前，Y向右，Z向上，单位厘米），而AirSim使用NED右手坐标系（X向北，Y向东，Z向下，单位米）。理解这两种坐标系的差异以及坐标转换公式（包含比例因子和Z轴反转）是理解CARLA-Air如何实现空地数据融合的关键。
研究动机
现有开源仿真平台存在领域隔离问题：自动驾驶仿真器（如CARLA）提供丰富的交通和行人群体，但缺乏空中动力学；多旋翼仿真器（如AirSim）提供精确的飞行物理，但缺乏真实的地面场景。尽管AirSim基于UE4构建，与CARLA共享相同的渲染引擎，但由于技术限制无法同时运行。同时，AirSim的上游开发已被归档，大量基于AirSim的研究缺乏持续的维护路径。这导致新兴的空地协同工作流（如无人机协助物流、移动充电、多智能体协调）缺乏统一的仿真基础设施。
本文的目标是本文的目标是创建CARLA-Air，一个将高保真城市驾驶和物理精确的多旋翼飞行统一在单一Unreal Engine进程中的开源基础设施。该平台旨在保留CARLA和AirSim的原生Python API和ROS 2接口，实现零修改的代码重用。在共享的物理时钟和渲染管线中，平台提供带有合规交通流、社会感知行人和空气动力学一致的多旋翼动力学的真实城市和自然环境，支持在每个仿真时刻同步捕获最多18种传感器模态（包括RGB、深度、语义分割、LiDAR、雷达、IMU、GNSS和气压计）。
与已有工作不同的是，本文的独特切入角度是从引擎级别的约束入手，直接解决UE4的单GameMode限制，而非通过桥接层绕过问题。与现有的桥接式共仿真方案（如TranSimHub通过ROS 2消息传递连接CARLA和SUMO）不同，CARLA-Air采用组合式设计，让CARLAAirGameMode继承CARLA的游戏模式基类，将AirSim的飞行角色作为常规世界实体组合进来。这种设计实现了共享的物理时钟、共享的渲染管线和严格的空间时间一致性，同时完全保留了两个上游的原生API，且对CARLA源码树的修改仅限于两个文件（约35行改动）。
核心方法
CARLA-Air的核心思路是将CARLA和AirSim整合到单一Unreal Engine进程中，通过最小化的桥接层解决引擎级初始化冲突，同时保留两个平台的原生API、物理引擎和渲染管线。平台采用双插件架构：地面仿真插件首先初始化，建立世界管理子系统；空中仿真插件声明对地面插件的编译时依赖，使CARLAAirGameMode能够在启动阶段访问地面平台的初始化接口。两个独立的RPC服务器在单一进程内并发运行，分别对应CARLA和AirSim的原生Python客户端。所有世界角色共享单一渲染管线，确保所有传感器视角的光照和天气一致性。
核心创新点是针对UE4单GameMode约束的组合式解决方案。CARLA的子系统通过继承紧密耦合到其游戏模式，而AirSim的飞行逻辑驻留在派生自通用角色基类的类中，而非游戏模式基类。这种架构不对称性使解决方案成为可能：CARLAAirGameMode继承CARLA的游戏模式基类并占据唯一的插槽，所有地面仿真子系统通过标准UE4生命周期获取；然后，空中飞行角色在引擎的BEGINPLAY阶段被组合到世界中，在地面初始化完成后，且从不竞争游戏模式插槽。这种设计让空地数据融合成为可能，同时完全保留了两个平台的API兼容性。
方法步骤详情
方法步骤包括：首先，系统启动时加载地面仿真插件，建立世界管理子系统（包括episode管理、天气控制、交通模拟、角色生命周期和RPC接口）。然后，空中仿真插件加载，声明对地面插件的依赖。接下来，CARLAAirGameMode继承CARLA的游戏模式基类，获取所有地面仿真功能。在引擎BEGINPLAY阶段，空中飞行角色被组合到世界中。最后，系统建立坐标系映射：CARLA使用左手坐标系（厘米单位），AirSim使用NED右手坐标系（米单位），通过坐标转换公式进行位置和姿态变换。运行时，两个独立RPC服务器并发运行，Python客户端通过TCP连接（CARLA使用端口2000，AirSim使用端口41451）。坐标转换涉及Z轴符号翻转和单位换算。
技术新颖性
技术新颖性体现在多个方面：首先，CARLA-Air是首个在单一进程中同时提供高保真城市交通、社会感知行人、基于物理的多旋翼飞行、保留原生API和单进程执行的统一仿真环境。其次，平台解决了UE4引擎级别的GameMode冲突，仅修改CARLA源码两个文件（约35行），而非重写整个架构。第三，平台支持同步捕获最多18种传感器模态（8种地面传感器+4种空中传感器+可能的扩展），所有传感器共享相同的tick索引和光照天气条件，实现了零插值的严格空间时间对应。最后，通过继承和扩展AirSim的空中仿真能力，平台为已归档的AirSim提供了持续的维护路径。
实验结果
性能评估实验表明，CARLA-Air在中等联合配置（3辆车辆+2名行人+1架无人机+8个传感器@1280×720）下达到19.8加减1.1 FPS，足以支持标准强化学习episode长度的闭环策略评估。与独立的地面基线（28.4 FPS）相比，总集成开销为8.6 FPS（30.3%），其中2.1 FPS归因于地面联合托管，6.5 FPS归因于空中物理引擎。关键发现是空中开销完全体现在CPU利用率上（54% vs 38%），而非GPU内存：地面only和中等联合配置之间的VRAM差异仅为39 MiB。3小时稳定性测试显示，在357次角色生成/销毁循环后，性能无下降（19.7加减1.3 FPS），零API错误，零仿真崩溃，VRAM回归斜率为0.49 MiB/cycle（R平方等于0.11），表明无显著内存累积。通信延迟测试显示，轻量级状态查询在280-490微秒内完成，远低于20 FPS的每帧预算（50毫秒）；角色生成延迟为1850微秒（反映GPU同步点），图像捕获延迟为3200微秒（覆盖渲染、缓冲区回读和序列化）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 空地协同精确着陆 | 最终水平误差 | < 0.5 m | 无（基线方案无法提供统一仿真） | 首次在统一物理环境中实现 |
| 同步多模态数据集采集 | 采集速率 | 17.1 FPS (12传感器流) | 桥接式方案 | 零插值对齐误差 vs 桥接方案的时钟漂移 |
| 跨视图感知（14种天气预设） | 天气一致性验证 | 14/14通过 | 无（基线方案不支持共享渲染管线） | 单次渲染管线传递确保一致性 |
| 强化学习训练环境 | 稳定性（357次重置循环） | 0崩溃，0内存泄漏 | 桥接式方案 | 单进程架构避免跨进程同步失败 |
局限与改进
作者承认的局限性包括：角色密度方面，联合仿真性能在中等交通负载下进行了表征；高密度场景（大量同时存在的角色群体）仍是活跃的工程目标。环境重置方面，地图切换需要完整的进程重启，因为每个仿真后端具有独立的角色生命周期管理；会话内分阶段重置计划在未来发布中提供。多无人机规模方面，超过两架无人机的配置功能正常但尚未在广泛场景中正式验证；多无人机行为的扩展表征将在相互代理行为完全分析后记录。作者还提到CARLA-Air继承了AirSim的空中能力，因此长期维护空中堆栈由CARLA-Air项目本身管理。
独立分析的弱点
CARLA-Air的一个潜在弱点是性能瓶颈主要来自传感器渲染（GPU内存带宽饱和）而非角色种群。这意味着在高分辨率多传感器场景下，帧率可能显著下降，限制了大规模多智能体仿真的可行性。另一个弱点是坐标转换引入的计算开销，虽然公式简单，但在高频tick（如1000 Hz空中物理）下可能累积。改进方向包括：实现GPU加速的传感器批处理以减轻渲染瓶颈；提供可配置的物理tick速率以在高精度和高吞吐量之间权衡；优化坐标转换路径，可能使用SIMD指令或GPU计算着色器。第三个弱点是缺乏对高密度场景的验证，这可能影响城市高峰时段的仿真现实性。改进方向是扩展角色管理系统的容量，优化draw call批处理，并实现LOD（细节层次）系统。
未来方向
作者提出的未来工作包括：解决物理状态在两个引擎之间的同步问题，实现ROS 2桥接以两种标准话题重新发布两个仿真器流，用于更广泛的生态系统集成。长期目标是支持GPU并行多环境执行，借鉴Isaac Lab和OmniDrones的设计，将CARLA-Air推向大规模强化学习所需的episode吞吐量。基于本文成果可延伸的方向包括：实现分布式仿真架构，支持多服务器协同以扩展角色规模；集成更多传感器模态（如热成像、事件相机）；支持自定义天气和光照条件的程序化生成；以及开发配套的数据标注工具链，加速空地跨视图数据集的构建。
复现评估
CARLA-Air的复现性评估显示，平台已发布预构建二进制包（约19 GB）和完整源代码（约651 MB，MIT许可证），支持立即采用。参考硬件配置为Ubuntu 20.04/22.04 LTS、NVIDIA RTX A4000（16 GB GDDR6）、AMD Ryzen 7 5800X（8核，4.7 GHz）、32 GB DDR4-3200。软件栈包括CARLA 0.9.16、AirSim 1.8.1（最终稳定开源版本）、Unreal Engine 4.26、Python 3.8加。所有实验在Epic质量模式和Town10HD地图下运行，空中实验使用内置SimpleFlight控制器和默认PID增益。API兼容性测试显示，所有89个自动化CARLA API测试通过无修改；完整的AirSim飞行控制和传感器访问API已通过手动和脚本测试验证。总计63个ROS 2话题在两个仿真后端发布。复现难度为低到中等：用户需要下载预构建包或编译源代码，按照文档配置端口和网络设置，然后可以运行五个代表工作流和三个性能基准。
论文图表
该折线图对比了桥接式共仿真（蓝色曲线）与CARLA-Air（橙色曲线）在每帧跨进程数据传输时间上的差异。横轴为并发传感器数量（1到16），纵轴为传输时间（毫秒）。桥接式方案呈现近线性增长：1个传感器时约1毫秒，8个传感器时约12毫秒，16个传感器时超过25毫秒，这反映了跨进程序列化的开销。CARLA-Air则保持在接近常数水平：即使有16个并发传感器，传输时间仍低于0.5毫秒（图中几乎与x轴重合）。图例标注了数据点取自文献[17]的桥接式共仿真。
这张图对理解论文非常重要，因为它量化了单进程架构相对于多进程桥接方案的性能优势。它证明了CARLA-Air消除了跨进程序列化开销，使得多传感器仿真的扩展性不再受通信瓶颈限制。这对于需要同步采集大量传感器模态的空地协同研究至关重要。
该二维散点图将CARLA-Air和代表性平台沿两个设计轴定位：仿真保真度（y轴，从轻量级到高保真）和智能体域广度（x轴，从单一域到多域）。CARLA-Air（红色星号）位于高保真、多域象限，是唯一不依赖跨进程桥接的平台。自动驾驶模拟器（CARLA、LGSVL、SUMO、MetaDrive、VISA）位于高保真、单一域；无人机模拟器（AirSim、Flightmare、FlightGoggles、Gazebo/RotorS、OmniDrones、gym-pybullet-drones）位于高保真、单一域；联合/共仿真平台（TranSimHub、CARLA加SUMO、AirSim加Gazebo）位于高保真、多域但依赖跨进程；具身AI平台（Isaac Lab、Isaac Gym、Habitat、SAPIEN、RoboSuite）位于高保真或轻量级、单一域，专注于可扩展学习而非空地基础设施。虚线箭头表示对上游能力的继承。
这张图对理解论文非常重要，因为它清晰地将CARLA-Air与现有平台区分开来，展示了其在高保真多域仿真中的独特定位。它帮助读者快速理解仿真平台的格局和CARLA-Air填补的空白。
该图展示了强化学习训练环境。顶部显示无人机在城市交通环境中学习保持对移动地面车辆的空中观察位置，周围有多辆自动驾驶车辆和行人。底部显示闭环强化学习流程：在每个同步tick，CARLA-Air提供观察空间（无人机和车辆姿态、相对距离、周围交通状态）给策略网络，策略网络输出3D速度命令作为动作。奖励信号编码跟踪精度、高度维持和碰撞避免。
这张图对理解论文非常重要，因为它展示了CARLA-Air作为强化学习训练环境的实用性，特别是其稳定性和适合闭环控制的特点。
该表格报告了环回接口上代表性API调用的往返延迟（中位数加减四分位距；5000次调用，500次预热；RTX A4000；空闲场景）。地面仿真：世界状态快照320加减40微秒，角色变换查询280加减35微秒，角色生成（配对销毁）1850加减210微秒，角色销毁920加减95微秒。空中仿真：多旋翼状态查询410加减55微秒，图像捕获（1个RGB流）3200加减380微秒，速度命令调度490加减60微秒。桥接IPC[17]跨进程状态同步（参考）3000加减2000微秒。
这个表格对理解论文非常重要，它量化了CARLA-Air的API延迟，证明了单进程架构相对于桥接方案的性能优势。