国産シミュレータ箱庭の思想と仕組み - PX4/ArduPilot対応のアーキテクチャ解説
この記事は、Qiitaに投稿した内容をZenn向けに再構成し、より思想的背景に重点を置いて再掲載したものです。
オープンソースのフライトコントローラの２大巨頭といえば、言わずと知れた「ArduPilot」と「PX4」。
これは、もはやドローン開発に関わる人にとっては常識とも言える存在です。
一方で、これらと連携してドローンの物理挙動を再現できるシミュレータといえばどうでしょうか？
どちらにも対応している有名どころとしては、「Gazebo」や「AirSim」が思い浮かびます。
さて、みなさん、Windowsでこれらを動かしてみたいと思ったことはありますか？
- WSLのインストールから始まり…
- PX4のビルドに失敗し…
- AirSim は既にサポート終了…
- Gazebo は Windowsでは動かず…
- ROS2のバージョン沼…
「一つ動かすのに一週間かかった」
そんな声を何度も耳にしました。
そこで今回は、こうした複雑な技術要素をまとめて統合し、
しかもWindows環境でもあっさり動くことで注目されている、
国産のオープンソースシミュレータ
「箱庭ドローンシミュレータ」の “仕組み” に焦点を当てて紹介します。
- なぜ、PX4とArduPilot、どちらもサポートできるのか
- なぜ、UnityやPythonとも連携できるのか
- なぜ、Windowsで手軽にサクサク動くのか
その答えは、箱庭のアーキテクチャの中にすべて詰まっています。
箱庭ドローンシミュレータのアーキテクチャ
これがその答えです。
１つずつ解説しましょう。
Physics
中央に箱庭ドローンと記載ありますよね。そこに、Physicsがあり、ドローンの物理挙動再現が行われる物理エンジンを組み込んでいます。デフォルトでは、数式ベースのドローン動力学の実装が入っています。
一方で、この物理モデルは、ドローン・ダイナミクスとして、MATLAB/Simulink で作成することもできます。また、高精度な剛体シミュレータである MuJoCo を組み合わせたドローンシミュレーションも可能な構成になっています。
ドローン制御
左のドローン制御内にあるフライトコントローラの２大巨頭 ArduPilot と PX4 があります。さらに、オリジナルのドローン制御を組み込むこともできる構成です。
また、デフォルトで組み込まれているドローン制御を Python API と連携してフライトシミュレーションさせることもできます。
外部環境
ドローン飛行時には、外部環境の影響はとても重要です。風や気温、ビルや建物などの障害物との接触もあります。これら外部環境との連携は、箱庭というシミュレーションプラットフォーム上で動作させることで、箱庭ドローンシミュレータとの連携が可能になるのです。
箱庭ブリッジ
箱庭ドローンシミュレータは、それ単体でシミュレーションすることは可能です。ですが、リアルドローンの運行管理との連携や、今流行りのデジタルツイン、リアルロボットやWeb/XR連携、さらにAIエージェントとの連携（MCP）などもあると夢が広がりますよね。
でも、箱庭はその夢を実現するプラットフォームであり、その仕組みが既にあるのです。
それが、箱庭ブリッジというコンポーネントです。これらがあることで、さまざまな応用が可能となり、単なるドローンシミュレータの枠を超えた壮大なシミュレーション環境になるポテンシャルを持っているのです。
いよいよ、なぜ？に答えていきましょう
なぜ、PX4とArduPilot、どちらもサポートできるのか
これ、箱庭ドローンシミュレータの内部モジュール構成です。
左上に PX4 と Ardupilot があります。実は、これらのフライトコントローラは、通信として TCP/UDPの違いがあります。PX4 は信頼性重視で TCP 通信です。Ardupilotは性能重視で UDP通信です。
そのため、箱庭ドローンシミュレータでは、通信モジュール comm を用意し、その差異を吸収しています。
そして、mavlink モジュールで PX4 と Ardupilot で通信プロトコルレベルでの差異を吸収し、service層では、PX4 でも Ardupilot でも同じ仕組みでシミュレーションできるようになっているのです。
右上にある Physics は、先に説明した物理モデル部分です。その物理モデルへのアクセスをセンサとアクチュエータとしてインタフェースを切った aircraft コンポーネントがあります。
service 層にある aircraft は、物理モデルへのアクセスを抽象化された aircraftコンポーネントを通してアクセスするのです。
そして、一番下にある hakoniwa コンポーネントが外部のモジュールである箱庭ブリッジへと橋渡ししていくというわけです。
箱庭ドローンシミュレータは、技術的にはシンプルなようで、実は緻密に設計されているのです。
なぜ、UnityやPythonとも連携できるのか
箱庭ドローンシミュレータでは、センサ情報やアクチュエータ制御など、すべての入出力が「PDU（Protocol Data Unit）」という形式で統一されています。
このPDUは、ROS IDL によって定義された構造体ベースのフォーマットであり、C/C++に加え、Python や C#（Unity）でも読み書きが可能です。言語に依存せず通信できるよう、コード生成や通信層の抽象化がなされています。
Unityとの連携：リアルタイム3D描画が簡単に
Unityと連携する場合は、以下のような構成で動作します。
中心となるのは、hakoniwa-webserverというコンポーネントです。これは、箱庭内部で流れるPDUデータ（たとえばドローンのTwistなど）を WebSocket 経由で外部にリアルタイム配信する仕組みを提供します。
Unity側では、hakoniwa-pdu-csharp パッケージを導入し、WebSocketのURIを設定することで、ドローンの姿勢・位置などを3D空間にリアルタイム描画できます。
このC#ライブラリはUnity向けに最適化されており、依存が少なく、導入後すぐにPDUデータを受信・可視化できます。
Pythonとの連携：制御ロジックを手軽に実装
箱庭の中核である hakoniwa-core は C 言語で書かれていますが、Pythonバインディングも提供されています。これにより、ユーザーは以下のような操作が可能です：
- Pythonからドローンの目標姿勢を送信（フライト指令）
- PDUとしてセンサ情報を受信し、AI/機械学習モデルで処理
- Unityや実機と組み合わせた複合的な制御試験にも活用可能
箱庭Webサーバ自体もPythonで書かれているため、拡張や改造も容易で、研究用途にも適しています。
そして、箱庭Webサーバは、箱庭PDUデータを Websocket 通信で共有するのです。
なぜ「連携」がここまで柔軟なのか？
それは、箱庭が次の3層構造を意識して設計されているからです：
① PDUによるデータ表現の共通化
② 通信手段（WebSocketなど）の抽象化
③ 各種言語・環境へのバインディングの整備
このアーキテクチャにより、箱庭ドローンシミュレータは、UnityやPythonだけでなく、Webアプリ、リアルロボット、AIエージェントとの連携までを視野に入れた拡張が可能となっているのです。
なぜ、Windowsで手軽にサクサク動くのか
箱庭ドローンシミュレータ、そしてその基盤である「箱庭」は、POSIX API 準拠で設計されています。
これにより、Linux / macOS / Windows（WSL）といった異なるOS間でもコードの移植性が非常に高く、実際、常にクロスプラットフォームでのビルド検証も行われています。
✅ POSIX準拠 → OS依存を排除 → クロスビルドが容易
そのため、Windowsネイティブのバイナリとして箱庭ドローンシミュレータを構築することも技術的には可能です。
しかし、実際にはPX4やArduPilotがWindowsネイティブ対応していないという根本的な課題が存在します。
無理に構成しようとすると、以下のようなアーキテクチャになります。
このように、WSL2 と Windows ネイティブアプリケーションの間で数ミリ秒単位の通信が頻発する構成では、体感で 4～5 倍の遅延を感じることすらあります。
そこで箱庭ドローンシミュレータでは、リアルタイム性と開発体験の快適さを両立する構成として、
- PX4/ArduPilotを含むコア部分をWSL2上のDockerコンテナで実行
- Unityとの通信をWebSocket（20ms周期）で非同期に接続
という構成を採用しています。
💡 UnityはWindowsネイティブ、箱庭はWSLコンテナ、通信はWebSocket →
OSを跨いでも安定したリアルタイム通信が可能
この工夫によって、Windows環境でも快適かつ正確なドローンシミュレーションが可能となっているのです。
「POSIXでクロス対応」＋「WebSocketでOSを越える」
技術的にはシンプル。でもこれが、現場の開発体験を劇的にラクにする仕掛けなんです。すごくない？
最後に
✨ 箱庭ドローンシミュレータが選ばれる理由
- ✅ ArduPilot / PX4 の両方に対応
- ✅ Python・Unity・Web との柔軟な連携
- ✅ Windows上でもサクサク動作
- ✅ リアルロボットやMCPとの応用展開も可能
💡 その理由は、シンプルで強力なアーキテクチャ
- PDUによる入出力の抽象化
- 箱庭ブリッジによる外部拡張性の担保
- POSIX＋WebSocket という現実的かつ堅実な実装方針
これらを貫くのは、「抽象化とブリッジ」という明快な思想です。
難解に見えて、実はとても筋が通った構造。それが、箱庭の“仕組み”です。
ご興味を持たれた方は、ぜひ以下のGitHubリポジトリから実際に触ってみてください。
👉 hakoniwa-drone-core GitHub リポジトリ
最新の開発状況や設計背景は、こちらの記事でもご紹介しています。
📘 開発思想とアーキテクチャの背景（2025年5月記事）
📣 Zenn読者の皆さんへ
ここまで読んでくださり、本当にありがとうございます。
もしこの記事が少しでも参考になったり、「面白い」と思っていただけたら、
公式ブログでも裏話や発展的な話題を発信していますので、ぜひのぞいてみてください。
Discussion