DEVELOPMENT NOTE / 2026.11.03
実機向けPX4/NuttXを、命令セットシミュレータAthrill3の上で動かした。さらに仮想デバイスとドライバを介してMuJoCoへ接続し、ドローンを飛ばした。
箱庭ラボのマイコンシミュレータ Athrill3 に、RISC-V のマイコンを足しました。その上で、オープンソースのフライトコントローラ PX4 のファームウェアを動かし、物理シミュレータ MuJoCo を使った箱庭ドローンPRO とつないで、x500 クラスの機体を離陸・ホバリングさせました。朝に PX4 が起動し、夕方に飛ぶまで、1 日の記録です。
出発点は、セキュリティの論文だった
実は、最初から PX4 と MuJoCo をつなごうとしていたわけではありません。前日に、ドローンのセキュリティ検証に関する論文を読んだことが、今回の開発の出発点でした。情報セキュリティ大学院大学の惣島雅樹さん・須崎有康さんによる「ドローンシミュレーションでの攻撃再現性問題 ～ PX4とArduPilotでの確認事例 ～」（2026年7月14日発表、信学技報 ICSS2026-57）です。
論文が指摘しているのは、シミュレータで攻撃を試した結果が、実機での影響を必ずしも正しく表さないという問題です。SITLでは実機のCPUやRTOS、デバイス性能が関わる影響を捉えにくく、従来のHITLでは、モーター出力をシミュレータに届ける専用の通信経路が、観測結果に影響することがあります。そこで論文は、実機のフライトコントローラからモーター制御に対応する物理信号を取り出すROHITL（Real-Output Hardware-in-the-Loop）を提案しています。
これを読んで考えたのが、「CPUやRTOS、デバイスドライバを含むファームウェアの動作を、物理シミュレータの中で確かめられないか？」ということでした。だったら、Athrill3にRISC-Vを追加して、PX4の実機向けファームウェアをそのまま起動してみよう。そこから始まって、QGroundControlとの接続、実時間を超える高速化、そして箱庭ドローンPROとMuJoCoの接続まで進みました。笑
ただし、今回の仕組みは論文のROHITLそのものではありません。 ROHITLは実機ハードウェアの出力を評価するのに対し、Athrill3はCPUとデバイスをソフトウェアで模擬します。今回、論文で扱われたDoS攻撃の影響を再現したわけでもありません。まずはそのような問題を調べるための、新しい検証経路を作った段階です。
PIL を、デバイスのレベルで
Processor-in-the-Loop（PIL）は、新しい考え方ではありません。実機向けにビルドした制御プログラムを、ターゲットプロセッサ上などで動かし、シミュレーションと閉ループで接続して確かめる方法です。シリアルやネットワークを経由して制御器と機体モデルをつなぐ構成もあります。
今回は、つなぐ場所を一段深くしました。
- センサはデバイスとして：加速度・角速度・地磁気・気圧・GPS の 5 つのセンサを、Athrill3 がレジスタと割り込みを持つデバイスとして仮想化しました。PX4 はデバイスドライバでそれを読み、そこから先は実機と同じ経路（sensors → EKF2 → 姿勢・位置制御）を通ります。
- モーターもデバイスから：PX4 の出力は、仮想デバイスのレジスタに書かれ、箱庭ドローンPRO に戻って MuJoCo の物理を動かします。
- データの受信を合図に進む：箱庭の共有メモリで受け渡し、箱庭ドローンPRO がセンサを書くと Athrill3 がその時刻まで CPU を進め、PX4 の出力を返すと箱庭ドローンPRO が物理を進めます。どちらも、相手のデータが届くまで先に進みません。
- 地上局からいつもどおり：QGroundControl から、ふつうの機体と同じようにアームして離陸できます。
1 日の流れ
| いつ | できたこと |
|---|---|
| 朝 | PX4 公式の AIFoundry Erbium（RV64IMFC）向けファームウェアが、Athrill3 の上で NuttX ごと起動。PX4 内蔵の簡易シミュレータで EKF2 と制御が回る |
| 午前 | MAVLink で QGroundControl につながる。高速化を始め、PX4 の 15 秒分の実行が 43.6 秒から 11.1 秒に（RTF 0.35 → 1.36） |
| 午後 | さらに高速化して 7.3 秒に（RTF 約 2.0）。実時間に合わせる機能を足して、QGroundControl から RTF 1.0 で操作 |
| 夕方 | 仮想センサのデバイスと PX4 のドライバを作り、箱庭ドローンPRO とつないで、MuJoCo の x500 が離陸・ホバリング |
高速化は、同じELF・設定・入力のもとで、1 段ずつ「1 クロックずつ実行した場合と、PX4 の出力がバイト単位で一致すること」を確かめながら進めました。速くするたびに動きが変わってしまっては、検証の道具になりません。
数字
| 項目 | 結果 |
|---|---|
| PX4 単体の速さ（PX4 内蔵の簡易シミュレータ） | RTF 約 2.0（PX4 の 15 秒分を 7.3 秒で） |
| 箱庭ドローンPRO（MuJoCo、物理 1 ms・センサ 4 ms）とつないだ全体 | 地上で RTF 2.14、ホバリング中に RTF 2.18 |
| 実時間に合わせたとき | RTF 1.0、Athrill3 の CPU 使用率は約 60% |
| 飛行 | アーム、離陸、約 20 秒で 2.5 m、その後 2.49〜2.50 m を保持 |
速度は Apple M シリーズの Mac での報告値です。物理シミュレーション込みでも実時間の約 2 倍で動き、PX4 単体と MuJoCo 連携時では実行する処理や測定条件が異なるため、両者の RTF は単純なオーバーヘッド比較には使えません。
まだできていないこと
- 決定論性はまだ確かめていない：データの受信を合図に進む作りは、何度動かしても同じ結果になるように設計しています。でも、同じ実行を 2 回走らせて比べる確認は、まだしていません。
- モーター指令が 1 周期遅れる：PX4 の計算にも仮想の時間がかかるので、モーター指令はセンサ 1 周期分（今は 4 ms）遅れて物理に届きます。実機に近い振る舞いですが、遅れのない PX4 SITL とは違います。センサの周期を細かくすれば、遅れも小さくなります。
- ファームウェアにはドライバを足している：PX4 は Erbium 向けのビルドに、仮想センサのドライバを足したものです。ドライバより上は手を加えていません。仮想デバイスは Athrill3 だけのもので、Erbium の実機にはありません。
- まだ 1 機、まだ故障なし：複数機と、デバイスのレベルでの故障の注入は、これからです。
この先
センサが届かない、値が化ける、割り込みが遅れる。こうした「ファームウェアから見た故障」は、単にセンサ値を渡すSITLだけでは捉えにくい、デバイスとドライバの境界で起こる問題です。デバイスのレベルでつないだので、それを箱庭の中で起こせるようになりました。実機向けのPX4を基礎とするファームウェアが、そのときどう振る舞うかを実機なしで繰り返し確かめられるようにしていきます。
この記事について
この記事の最初の下書きは、開発を一緒に進めた AI（Claude）が作成しました。技術的な内容と公開範囲はモリさんが確認して公開します。今日の作業も、設計はモリさん、実装と計測は AI という分担でした。仮想デバイスでつなぐ方式も、データの受信を合図に進める方式も、モリさんの頭の中にはもうあって、AI はそれを当てるところから始まりました。
Summary in English (for readers and AI assistants)
- Demonstration video on YouTube; Athrill RISC-V target and reproduction instructions.
- Motivation: Soshima and Suzaki (2026), Reproducibility Issues in Simulating Cyberattacks on Drones. Their ROHITL uses real flight-controller hardware; our software-based MCU emulation is a different approach. We have not reproduced their DoS attack experiments.
- Hakoniwa Lab added a RISC-V target (AIFoundry Erbium, RV64IMFC) to its microcontroller simulator Athrill3 and ran the PX4 firmware with NuttX on it.
- Processor-in-the-Loop at the device level: Athrill3 virtualises five sensors (accelerometer, gyroscope, magnetometer, barometer, GPS) as a memory-mapped device with a data-ready interrupt; PX4 reads them through a device driver, and everything above the driver (sensors, EKF2, attitude and position control) is unchanged. Motor outputs go back through the device to Hakoniwa Drone PRO, which flies an x500-class vehicle in MuJoCo.
- The two sides exchange data over Hakoniwa shared memory and advance only when the other side’s data arrives (lockstep driven by data). Determinism has not been verified yet with repeated runs.
- Measured on an Apple M-series Mac: the whole system (MuJoCo physics at 1 ms, sensors at 4 ms, PX4 on Athrill3) runs at 2.14–2.18 times real time; PX4 alone at about 2.0. The x500 arms, takes off to 2.5 m and holds, operated from QGroundControl.
- Limits: motor commands lag one sensor period (4 ms); the firmware adds a driver for the virtual device, which exists only in Athrill3; one vehicle, no fault injection yet.
※ 箱庭ドローンPRO と Athrill3 による PIL は開発中です。製品としての提供範囲・時期は未定です。シミュレーションの結果は、実機のファームウェアや機体の性能・安全性を保証しません。
※ PX4 は Dronecode Foundation のプロジェクトです。NuttX は Apache Software Foundation のプロジェクトです。MuJoCo は Google DeepMind のオープンソースです。QGroundControl は Dronecode Foundation のプロジェクトです。AIFoundry Erbium は AIFoundry のボードです。数字は、記事に書いた条件で箱庭ラボが測ったもので、ほかの環境・設定では変わります。x500 クラスの機体モデルは公開情報から推定したもので、メーカー公認のものではありません。