← Flecto
▲ 332 upvotes

CARLA-Air: CARLAワールド内でドローンを飛行させる

空地複合知能のための統合インフラストラクチャ

Tianle Zeng, Hanxuan Chen, Yanci Wen, Hong Zhang — Southern University of Science and Technology & Hunan University

Read on arXiv ↗ GitHub ↗

アブストラクト (または 抄録)

低高度経済、具現化された知能、および空地協働システムの収束は、単一で物理的に一貫性のある環境内で空域および地上のエージェントを共同でモデル化できるシミュレーションインフラストラクチャに対する高まるニーズを生み出している。既存のオープンソースプラットフォームは、特定のドメインに留まっている。都市運転シミュレータは豊かな交通を提供するが空域力学は提供せず、一方マルチローターシミュレータは物理学的に正確な飛行を提供するものの、リアルな地上シーンが不足している。

CARLA-Airは、高忠実度の都市走行と物理的に正確なマルチローター飛行を単一のUnreal Engineプロセス内で統合するオープンソースのインフラストラクチャです。CARLAとAirSimの両方のPython APIを維持し、最大18の同期センサーモダリティによる写真のようにリアルなレンダリングを可能にし、多様なシナリオ向けにカスタムアセットのインポートをサポートします。このプラットフォームは、協調的着陸、ビジョン・言語ナビゲーション、マルチモーダルデータセット収集、クロスビュー認識、および強化学習にわたる5つの代表的なアプリケーションワークフローを通じて、性能ベンチマークによって検証されています。

CARLA-Air teaser figure
Figure 1: CARLA-Airは、ドローン、車両、および歩行者が共有の都市シミュレーション世界で共存できるようにし、カスタムアセット、ビジョン・言語ナビゲーション、マルチモーダルセンサー、および多様なシナリオカバレッジをサポートします。
航空・地上エージェント 単一の UE4 プロセス 18 センサー様式 カスタムアセットインポート オープンソース アプリケーションワークフロー 5点

なぜ CARLA-Air なのか？

三つの交差するフロンティアが自律システム研究を再構築しています。すなわち、低高度経済は都市空飛ぶ移動やドローン物流のためのスケーラブルなインフラを要求し、具現化された知能はフォトリアリスティックな環境で知覚し行動するエージェントを必要とし、そして空地協調は共有された世界内での共同の航空・地上推論を要求しています。

問題点: 既存のシミュレーターはドメイン特有です。CARLAは都市走行に優れていますが、航空ダイナミクスがありません。AirSimは物理的に正確な飛行を提供しますが、現実的な地上交通が不足しています。ブリッジベースのコシミュレーションアプローチ（2つのシミュレーターを個別のプロセスとして実行）は、同期オーバーヘッドを導入し、厳密な時空間的一貫性を保証することができません— センサーが増えるにつれて、フレームごとのデータ転送遅延が1msから20ms以上に増加します。

「ブリッジベースの共同シミュレーション」とは何ですか？

コンピューターで2つの別々のビデオゲームを動かし、それらをリアルタイムで同期させようと想像してみてください。これこそが本質的に「bridge-based co-simulation（ブリッジベースの共同シミュレーション）」が行っていることです。これは、CARLA（ドライビングシム）とAirSim（ドローンシム）という2つの独立したプログラムを動かし、ネットワーク接続を通じてそれらの間でデータをやり取りします。問題点は？ドローンが車を「見る」たびに、その視覚データがプロセス間で移動する必要があり、遅延が発生します。センサーが16個ある場合、この遅延はフレームあたり20msに達し、リアルタイム要件を崩すのに十分な量となります。CARLA-Airは、すべてを単一のプログラムにまとめることで、これを解消しています。

CARLA-Airは、両方のプラットフォームを単一のUnreal Engine 4プロセスに統合することで、この問題を解決します。別のプロセスをブリッジする代わりに、CARLAの地上サブシステムを継承し、AirSimの空中飛行アクターを統一されたGameMode内で構成します。これにより、プロセス間通信が完全に排除され、センサー数にかかわらずサブミリ秒のデータ転送を達成します。

Simulator comparison landscape
図2: シミュレーターの領域比較。CARLA-Airは、CARLA (地上) と AirSim (空中) の両方の強みを組み合わせ、マルチドメインエージェントサポートを備えた、以前は空白であった高忠実度シミュレーションの象限を占めている。

システムアーキテクチャ

CARLA-Airは、最小限のブリッジング層を介して、CARLAとAirSimを単一のUnreal Engineプロセス内に統合します。重要な洞察は、コンポジションベースのデザインです。CARLAAirGameModeは、CARLAのGameModeBaseから継承し、すべての地上シミュレーションサブシステム（エピソード管理、天候、トラフィック、アクター、シナリオレコーダー）を取得し、一方、AirSimの空中飛行アクター（物理エンジン、飛行ポーン、空中センサースイート）は、BeginPlay中に標準的なワールドエンティティとして構成されます。両方のPython APIは、個別のRPCサーバーを介して同じUE4プロセスに接続し、RGB、深度、セグメンテーション、および天候エフェクトのための統一されたレンダリングパイプラインを共有します。

GameModeデザインパターンを理解する

Unreal Engine（CARLAとAirSimの両方を動かすゲームエンジン）において、GameModeはシミュレーションの「オペレーティングシステム」のようなものです。これは、どのようなアクターが存在するか、物理学がどのように機能するか、どのようなルールが適用されるかを制御します。注意点として、UE4では一度に一つのGameModeしか許可されていません。

  • 問題点： CARLAには独自のGameMode（車、交通、歩行者用）があり、AirSimにも独自のGameMode（ドローン、飛行物理学用）があります。両方を同時に実行することはできません。
  • 解決策： CARLA-Airは、新しいGameMode（CARLAAirGameMode）を作成します。これは、CARLAの地上能力（子クラスのようなもの）を継承し、AirSimの航空能力（プラグインの追加のようなもの）を合成するものです。これは、古典的なソフトウェア工学パターンである「継承 + 構成（composition）」です。
  • 現実世界の類推： これは、2台の携帯電話を並べるのではなく、両方のアプリ形式をネイティブに理解する単一のOSを構築することで、iOSアプリとAndroidアプリの両方を実行できるスマートフォンに例えることができます。
CARLA-Air system architecture
図3: CARLA-Airシステムアーキテクチャ。Python CARLAおよびAirSimクライアントは、独立したRPCサーバーを介して、CARLAAirGameModeを実行している単一のUE4プロセスに接続し、これは地上サブシステム（inherited）と空域飛行アクター（composed）を統合する。

主要設計決定事項

ゲームモード コンフリクト解決

Unreal Engineでは、ワールドにつきアクティブなGameModeは1つのみ許可されています。CARLAとAirSimの両方のGameModeをロードするという素朴なアプローチはサイレントに失敗し、一方のモードが破棄され、そのAPIが無効になります。CARLA-Airは、inheritance + compositionを通じてこれを解決します：CARLAAirGameModeは、CARLAのGameModeBase（地上サブシステムを取得）を継承し、AirSimのフライトアクターを独立したエンティティとしてコンポーズ（結合）し、両方とも単一のGameModeスロットに収まるようにしています。

GameMode conflict resolution

座標系マッピング

UE4/CARLA は 左手系座標システム (Z軸上向き、センチメートル) を使用し、一方 AirSim はメートル単位で NED (北-東-下) を使用します。CARLA-Air は、両方のAPIが一貫した位置を報告することを保証する、Zフリップとスケール変換 (cm ↔ m) を処理するリアルタイムの座標変換レイヤーを維持しています。

NED Coordinate System

NED は North-East-Down の略であり、航空分野における標準的な座標系です。このシステムでは、X軸が北を、Y軸が東を、そしてZ軸が下方（downward）を指します。これは、Z軸が上を指すUE4のゲーミングの慣例とは逆です。CARLA-Air は、これら2つのシステム間で自動的に変換を行うため、AirSim の API によって報告されるドローンの位置が CARLA のワールド内の対応する場所と一致します。

Coordinate system mapping

アセットインポートパイプライン

CARLA-Airは、カスタムの3Dアセット（車両、ロボット、ドローン）をシミュレーションにインポートするための合理化されたパイプラインを提供します。ユーザーは、独自のモデル（モバイルロボットからスポーツカーまで）を持ち込むことができ、これによりデフォルトのアセットライブラリを超えた多様な研究シナリオが可能になります。

Custom asset import

機能比較

CARLA-Airは、地上車両、空中エージェント、高忠実度物理演算、豊富なセンサー群、マルチエージェントサポート、天気シミュレーション、カスタムアセットインポート、およびオープンソースでの利用可能性といった全ての主要機能を網羅した唯一のプラットフォームです。

PlatformGroundAerialPhysicsSensorsMulti-AgentWeatherCustom AssetsOpen Source
CARLA [2]✓✗✓✓✓✓✓✓
AirSim [15]✗✓✓✓✓~✓✓
Isaac Lab [11]✓~✓✓✓✗✓✓
Habitat [14]✗✗~✓✓✗✓✓
SUMO [8]~✗✗✗✓✗✗✓
MetaDrive [7]✓✗~✓✓~~✓
OmniDrones [19]✗✓✓✓✓✗✓✓
TranSimHub [17]✓~~~✓~~✓
CARLA-Air (Ours)✓✓✓✓✓✓✓✓

業績評価

すべてのベンチマークは、Unreal Engine 4.26上で動作するCARLA 0.9.15を使用し、NVIDIA RTX 4090 GPUを搭載した単一のワークステーションで実施されました。3つの実験では、フレームレートスケーリング、メモリの安定性、および通信遅延が評価されました。

30+
FPS

1280×720における、地上車両、歩行者、およびドローンによるマルチドメインシミュレーション

~0.4%
VRAM growth

357回のリセットサイクルを伴う3時間超の連続稼働 — メモリリークは検出されませんでした

<0.5ms
latency

16センサーによるブリッジベースの共同シミュレーションの20msと比較した、フレームごとのデータ転送

フレームレートとリソースのスケーリング

航空ドメインを追加してもオーバーヘッドは最小限です：地上のみのCARLAは28.4 FPSを達成し、一方マルチドメインのCARLA-Airは、同等のワークロード下で19.8–26.3 FPSを維持します。これは、インテグレーションレイヤーに起因する5%未満のFPS低下にすぎません。航空のみの構成では44.7 FPSで動作し、フライト物理エンジンが軽量であることを確認しています。

「5%未満のFPS低下」はなぜ印象的なのか？

既に複雑なドライビングシミュレーターの上に、完全なフライトシミュレーションシステム（物理エンジン、ドローンセンサー、空中レンダリング）を追加する場合、大幅なパフォーマンスの低下が予想されます。CARLA-Airがフレームレートの低下を約5%に抑えているという事実は、その統合レイヤーが極めて軽量であることを意味します。比較として、同じシミュレーションを別個のプロセスとして実行する場合（ブリッジアプローチ）は、フレームごとに20msの通信オーバーヘッドが追加され、これは30 FPSでの使用可能なフレームレートを実質的に半分にしてしまいます。

ConfigurationScenarioFPSVRAM (MiB)CPU (%)
Ground only3 vehicles + 2 peds; 8 sensors @ 1280x72028.4 ±1.23,821 ±1031 ±3
Aerial only1 drone; 8 sensors @ 1280x72044.7 ±2.12,941 ±829 ±3
BaselineTown10HD; no actors; no sensors60.0 ±0.43,702 ±812 ±2
Multi-domain3 vehicles + 2 peds; 8 sensors @ 1280x72026.3 ±1.43,831 ±1138 ±4
Multi-domain3 vehicles + 2 peds + 1 drone; 8 sensors @ 1280x72019.8 ±1.13,870 ±1354 ±5
Multi-domain8 autopilot vehicles + 1 drone; 1 RGB @ 1920x108020.1 ±1.83,874 ±1561 ±6
Stability testModerate joint; 357 reset cycles; 3 hr19.7 ±1.33,878 ±1755 ±5

メモリー安定性

VRAM memory stability
Figure 7: 3時間の連続実行におけるVRAM使用量。初期フェーズの平均は 3,862 MiB、後期フェーズの平均は 3,878 MiBであり、増加率はわずか ~0.4%にすぎません。

357回のスポーン/デストロイサイクルを伴う3時間の連続安定性テストの間、VRAM使用量は約3,870 MiBで安定していました。初期から後期にかけての増加は~0.4% (16 MiB)に過ぎず、メモリリークがないことを確認しました。シミュレーションはクラッシュゼロで完了し、本番環境レベルの信頼性を示しました。

通信遅延

Communication latency comparison
図8: フレームごとのデータ転送比較。Bridgeベースの協調シミュレーションのレイテンシはセンサー数に比例して増加する（1～20ms）のに対し、CARLA-Airはセンサー数に関わらず<0.5msを維持する。

CARLA-Airはすべてのデータを単一プロセス内に保持するため、同時センサーの数に関係なく、フレームごとのデータ転送は0.5 millisecondsを下回ります。対照的に、bridge-basedの共シミュレーションの遅延は線形に増加し、16センサーの場合20msに達します。個々のAPI操作（world state queries、actor spawning、image capture）は、bridgeの同等物よりも4–10× fasterです。

ここでマイクロ秒が重要となる理由

30 FPSの場合、各フレームには約33ミリ秒の予算が割り当てられています。16センサーを使用したブリッジの共シミュレーションでは、データ転送だけで20msを消費し、実際の計算に充てられるのはわずか13msに過ぎません。しかし、CARLA-Airの0.5ミリ秒未満の転送は、フレームの予算のほぼ全てを有用な作業（物理演算、レンダリング、AI）に回すことを意味し、リアルタイムのマルチセンサーシミュレーションを実現可能にしています。

OperationBridge (μs)CARLA-Air (μs)
World state snapshot32040
Actor transform query28035
Actor spawn1,850210
Image capture (1 RGB)3,200380
Velocity command49060
Cross-process sync (ref.)3,0002,000

代表的なアプリケーション

CARLA-Airは、共有環境で動作する空中のエージェントと地上のエージェントの両方を必要とする、幅広い研究ワークフローを可能にします。このプラットフォームの多様性を示す5つの代表的なアプリケーションを紹介します：

空地共同精密着陸

ドローンは、共有ワールドステートを使用して、移動する地上車両を自律的に追跡し、着陸します。このシステムは、地上クライアント（車両軌道）と空中クライアント（ドローン飛行コントローラー）の両方を制御する、統一されたPythonスクリプトを使用します。ドローンのアプローチ、降下、および着陸フェーズは、リアルタイム共有ポジショニングを通じて調整され、0.5m以内の水平収束を達成します。

W1 workflow diagram
Figure 9: W1 workflow — 単一のPythonスクリプトが、共有のUE4プロセス内で、地上および空中からのRPCクライアントの両方を調整します。
W1 precision landing results
図10: 高精度な着陸結果: (a) アプローチ中のカメラフレーム、(b) アプローチ→降下→着陸を示す3D軌道、(c) 標高プロファイル、(d) <0.5mに収束する水平誤差。

W2: Embodied Navigation & VLN/VLA データ生成

CARLA-Airは、Vision-Language Navigation (VLN)およびVision-Language-Action (VLA)モデルの訓練データを生成します。ドローンは、"Fly across the bridge to the city center."のような自然言語の指示に従って、都市環境を航行します。このプラットフォームは、ペア化された視覚的観察と行動軌道を収集することで、研究者が空中からの視点から、視覚的なシーンと言語コマンドの両方を理解する具現化されたエージェントを訓練できるようにします。

VLNとVLAの説明

Vision-Language Navigation (VLN) は、AIエージェントが自然言語の指示（例：「ドローンに『橋を渡って街の中心部まで飛んで』など」）に従って物理的な環境をナビゲートする研究分野です。エージェントは、正しくナビゲートするために、言語と視覚シーンの両方を理解する必要があります。

Vision-Language-Action (VLA) は、さらにモーターコマンドを生成することでこれを拡張しています。エージェントは単に経路を計画するだけでなく、何を見て何を聞いたかに基づいて、制御信号（速度、方向）を直接出力します。CARLA-Airは、大規模にペア化された視覚・言語・行動データ（visual-linguistic-action data）を生成することにより、これらのモデルのトレーニング環境を提供します。

W3: 同期マルチモーダルデータセット収集

CARLA-Airは、空中および地上の両方からの視点から、時間同期されたマルチモーダルデータを同時に収集します。両方のセンサースイートが同じ物理ティック内で動作するため、データは完全にアライメントされており、事後的な同期は不要です。このプラットフォームは、両方の視点からRGB、深度、セマンティックセグメンテーション、オプティカルフロー、サーフェスノーマル、およびLiDARを含む最大18種類のセンサーモダリティを捉えます。

W3 aerial snapshots
W3 multi-modal sensor grid
Figure 13: CARLA-Airから得られた、地上および航空の視点からの、RGB、深度、セグメンテーション、オプティカルフローなどを含むマルチモーダルセンサー出力。

W4: 空中・地上クロスビュー認識

このワークフローは、同じシーンの空撮および地上レベルのビューをマッチさせるようにモデルを訓練します。CARLA-Airは、6つのマップ×7つの気象条件（快晴の正午、曇り、濃霧、大雨、夜、小雨、日没）にわたる系統的なデータ収集をサポートし、ロバストなクロスビュー知覚研究のために包括的な視覚的多様性を提供します。

W4 weather and map variations
Figure 14: 6つのCARLAのタウンと7つの天候条件にわたるクロスビューの認識データセットサンプルであり、ロバストな認識モデルの訓練に利用可能な環境の多様性を示しています。

W5: 強化学習トレーニング環境

CARLA-Air は、ドローンナビゲーションタスクのための Gymnasium-compatible RL environment を提供します。観測空間には、ドローンのRGB画像、深度マップ、ポーズ情報、およびNPCの車両位置が含まれます。アクション空間は、速度コマンド（Δvx、Δvy、Δvz）を制御します。報酬関数は、目標への進行、高度ボーナス、および衝突ペナルティを組み合わせています。r = rprogress + raltitude − rcollision。

RL Environment Design Basics

強化学習（RL）は、試行錯誤を通じてエージェントを訓練します。これは、おやつを使って犬に新しい芸を教えるようなものです。CARLA-Airが提供する主要なコンポーネントは以下の通りです。

  • Observation Space: ドローンが「見る」もの、つまりRGB画像、深度マップ、自身の位置、および他の車両の位置
  • Action Space: ドローンが「できる」こと、つまり3Dでの速度変化（前方/後方、左/右、上/下）
  • Reward Function: 「おやつ」— 目標車両に近づいた場合のポジティブな報酬、適切な高度を維持することへのボーナス、衝突に対するペナルティ

Gymnasium互換のインターフェースにより、研究者はカスタム統合作業なしに、標準的なRLアルゴリズム（PPO、SAC、DQN）を組み込むことができます。

W5 RL environment
Figure 15: W5 RL pipeline — CARLA-Air は、ポリシーネットワークに対し、観測空間と行動空間を提供し、ドローンと車両の近接性および衝突回避に基づいた報酬を付与する。

制限事項と今後の課題

CARLA-Airの現行リリースは、上記で提示された5つのワークフローに対して検証されています。いくつかの制約が、アクティブなエンジニアリング目標として残っています。

今後の方向性

近期の作業には、2つのエンジン間の物理状態同期と、より広範なエコシステム統合のためのROS 2 bridgeが含まれます。長期的な目標には、大規模RLのエピソードスループットを増やすためのGPU並列マルチ環境実行（Isaac Labに類似）と、Unreal Engine 5への移行の可能性が含まれます。AirSimのアップストリーム開発がアーカイブされたため、CARLA-Airは、バグ修正と機能拡張を伴って、エアリアルスタックを独立して維持しています。

結論

自動システム向けのシミュレーションプラットフォームは、歴史的にドメイン境界に沿って断片化しており、研究者はプロセス間ブリッジインフラストラクチャを維持するか、機能性の妥協を受け入れることを余儀なくされてきた。CARLA-Airは、高忠実度な都市走行（CARLA）と物理学的に正確なマルチローター飛行（AirSim）を単一のUnreal Engineプロセス内に統合することにより、この断片化を解決する。

本分野における重要性

CARLA-Air以前、空対地協力を研究する研究者は、(a) 別々のシミュレーター間で複雑なブリッジインフラを維持し、パフォーマンスのペナルティや同期のバグを受け入れるか、または(b) 現実性を犠牲にした簡素化されたカスタム環境を構築する必要がありました。CARLA-Airは、これらの妥協なしに高忠実度のマルチドメインシミュレーションを可能にする最初のプラットフォームであり、オープンソースであるため、コミュニティの共有標準となり得ます。

中心的な技術的貢献は、UE4の単一GameModeの制約を解決するcomposition-based GameMode designです。これにより、ゼロのプロセス間遅延、CARLAとAirSimの両方との完全なAPI互換性、および共有レンダリングパイプラインが実現します。本プラットフォームは、共同のワークロードの下で約20 FPSの安定した動作を維持し、3時間の連続実行を通じてもクラッシュはゼロです。

5つの代表的なワークフローは、単一ドメインプラットフォームでは構造的にアクセス不可能な機能を示します。これらは、協調的な空地着陸、空撮視点からの視覚言語ナビゲーション、同期的なマルチモーダルデータセット収集、クロスビュー知覚、およびRLトレーニングです。CARLA-Airは、プリビルトバイナリと完全なソースコードとともにオープンソースとしてリリースされています。

参考文献（20論文）
  1. [1] Amini et al. VISTA 2.0: An open, data-driven simulator for multimodal sensing and policy learning. IEEE RA-L, 2022.
  2. [2] Dosovitskiy et al. CARLA: An open urban driving simulator. CoRL, 2017.
  3. [3] Epic Games. Unreal Engine 4 documentation, 2021.
  4. [4] Furrer et al. RotorS — a modular Gazebo MAV simulator framework. ROS, 2016.
  5. [5] Guerra et al. FlightGoggles: Photorealistic sensor simulation. IROS, 2019.
  6. [6] Koenig & Howard. Design and use paradigms for Gazebo. IROS, 2004.
  7. [7] Li et al. MetaDrive: Composing diverse driving scenarios. IEEE TPAMI, 2022.
  8. [8] Lopez et al. Microscopic traffic simulation using SUMO. ITSC, 2018.
  9. [9] Macenski et al. Robot Operating System 2. Science Robotics, 2022.
  10. [10] Makoviychuk et al. Isaac Gym: High performance GPU-based physics simulation. NeurIPS, 2021.
  11. [11] NVIDIA. Isaac Lab: A unified framework for robot learning. arXiv, 2025.
  12. [12] Panerati et al. Learning to fly — a gym environment with PyBullet. CoRL, 2021.
  13. [13] Rong et al. LGSVL Simulator. ITSC, 2020.
  14. [14] Savva et al. Habitat: A platform for embodied AI research. ICCV, 2019.
  15. [15] Shah et al. AirSim: High-fidelity visual and physical simulation. FSR, 2017.
  16. [16] Song et al. Flightmare: A flexible quadrotor simulator. CoRL, 2020.
  17. [17] Wang et al. TranSimHub. arXiv, 2024.
  18. [18] Xiang et al. SAPIEN: A simulated part-based interactive environment. CVPR, 2020.
  19. [19] Xu et al. OmniDrones: RL in drone control. arXiv, 2023.
  20. [20] Zhu et al. robosuite: A modular simulation framework. arXiv, 2020.

B2B Content

あらゆるコンテンツを、御社向けに美麗に制作します

PDF・動画・Webページ等のあらゆる素材から、プロダクション品質のコンテンツを制作します。リッチHTML・カスタムスライド・アニメーション動画。

サービス詳細を見る お問い合わせ