箱庭ラボの開発風景

前回のブログ更新からだいぶ時間が経ってしまいました。

（週２回更新を目標にしていますが、なかなか目標達成させることができずにいます…。）

さて、今回は、箱庭ラボの開発風景を共有してみたいと思います。

箱庭ラボの戦略

これ、箱庭ラボの戦略です。

箱庭ラボの基本方針として、少なくとも３年間はシーズを中心にした活動を進めています。

ビジネスの方向性としては、

「シーズ中心の広報活動を展開し、”熱い場所”を見つけて火をつけに行く」

という考え方を持っています。

ここでいう”熱い場所”とは、情熱的に活動している人々が集まる場所のことです。

この戦略を基に、箱庭という独自性と面白さを持つ火種が、熱い場所で燃え広がっていく中で、新しい世界が切り拓かれていくことを期待しています。

箱庭ラボの活動内容

そんな戦略でいますので、日々の活動は、以下の２つの活動が基本となっています。

箱庭の技術開発を推進する活動
箱庭の技術について情報共有する活動

箱庭ラボが設立されてから約２ヶ月半経ちました。この間、SWESTやROSConJPなどの様々なイベントの参加、さらに大阪万博向けの打ち合わせなど、多岐にわたる活動を中心に進めてきました。

ただ、最近気がついたこととして、箱庭ラボとして集中して技術開発を進めていなかった点があります。

そこで、先週から新たな技術チャレンジ、「ドローン・シミュレータ」に取り組むことにしました。

（ちなみに、これがブログの更新が遅れていた一因です。）

なお、箱庭のドローン・シミュレータ構想は、箱庭合宿のブログで一度ご紹介しております。

箱庭のドローン・シミュレータ構想とチャレンジ内容

箱庭としてドローン・シミュレータにチャレンジしたい理由はいくつかあります。

ドローンのシミュレーションでは高い精度が求められること
シミュレーションハブである箱庭が、MATLAB/Simulinkとの連携が可能であることを示すこと
物理エンジンとビジュアライズ機能を分離した構成でのシミュレーションを可能にすること

箱庭は、これまでUnityを前提としたシミュレーションしかできませんでしたが、箱庭はシミュレーションハブですので、物理エンジンはUnity以外のものにすることが可能です。

ドローンのようなシミュレーションでは、高い精度のシミュレーションが求められますので、物理エンジン部分はUnity以外の選択を可能としたいと考えています。

ですので、箱庭ドローン・シミュレータの物理エンジン部分は、MATLAB/Simulinkで設計された物理モデルを実行させる構想を描いています。

MATLAB/Simulinkを選択する大きな理由は、高い計算精度でのシミュレーションが期待できるためです。また、これによってリアルタイムでのシミュレーションが可能になり、より現実に近いドローンの飛行状態を再現することができます。

そして、３Dビジュアライズに関しては、ドローンの位置情報をUnity側と共有することで実現します。

また、箱庭でドローン・シミュレータが実現できると、将来的に以下のようなユースケースにも対応できます。

物流と連携したシミュレーション
電波干渉問題や故障ケースを考慮した異常系テスト
実機と箱庭を繋げたHILS構成のテスト

なぜなら、箱庭はシミュレーションハブであるため、さまざまなシミュレータやテスト機能、さらには実機との連携が可能であるためです。

そう言う意味で、箱庭ラボとして、ぜひチャレンジしたい！と常々思っていました。しかし、新しい技術やアプローチを導入する際の多くの障壁や、既存のプロジェクトの優先順位など、様々な要因があり、行動に中々移せないというジレンマがありました。これを乗り越えるための取り組みや計画も進めている中で、今回この新しいチャレンジを始めることができました。

先週の開発内容

さて、いよいよ本題へと移ります。

箱庭のドローン・シミュレータの大枠のアーキテクチャは既に考えていましたが、具体的な要素技術についてはまだ手をつけていませんでした。

そこで、最初のステップとして、PX4のアーキテクチャを深く理解すること、そしてそれをビルド・動作させることから始めました。

最終的な目標は、箱庭とPX4をどのように繋げるか、その道筋を立てることです。

ちなみに、PX4については全く知らない状態からの出発でしたので、とても苦労しました…。

１日目：PX4の理解

開発者向けのPX4のアーキテクチャは、以下で公開されています。

https://docs.px4.io/main/en/development/development.html

今回、箱庭向けに読み込んだところは以下です。

これらの情報を読み込んでいく中で、面白い発見がありました。

実は、PX4には、SITL(Software In The Loop)のための仕組みが用意されており、GazeboやAirSim、jMAVSim などがプラグインできる構成でした。

当初は、PX4のDriverやHAL層をLinuxプロセスかマイコンシミュレータで差し替える構想を描いていましたが、このような仕組みがあるのであれば、まずはここから進めることが近道だと感じました。これらの新たな情報を基に、当初の箱庭のアーキテクチャを微修正することにしました。

２日目：PX4のビルド

PX4はオープンソースであり、以下のURLで公開されています。

https://github.com/PX4/PX4-Autopilot

そして、ビルド環境は、自分が愛用している M2MacBookPro と docker の組み合わせで始めることにしました。

しかし、期待通りには進まず、ビルドの道のりは険しくなりました。Qiitaやブログを参考にしながらのビルド作業を着手しました。しかし、「ビルドが通らない！」や「ビルドは成功したのにPX4が起動しない！」という壁に幾度となく直面しました。

試行錯誤の結果、現在ではWindows 11のWSL2環境下でのビルドが一番安定しており、そこでSITL上のPX4を問題なく起動できることが確認できました。

とはいえ、どこかのタイミングで M2MacBookProへの再チャレンジは絶対にします！

ビルド環境は以下で公開しています。

https://github.com/tmori/px4-build

３日目：PX4との結合確認

PX4 on SITL は、外部のシミュレータとの連携が可能です。

その連携は、TCP通信でのMAVLinkを利用した通信に基づきます。TCP通信では、シミュレータ側がサーバーとなって、4560ポートで待ち受けします。また、MAVLinkとは、ドローン向けの通信プロトコルで広く利用されているものです。

さらに、PX4は、QGroundControlとも連携できます。QGroundControlとは、PCやタブレット上で動作するもので、ドローンにコマンドを送ったり、ドローンから送られてくるセンサデータなどを表示するためのアプリケーションです。

PX4 on SITL との通信は、UDPベースで行います。PX4側は 18570ポート、GGroundControl側は14550ポートです。

これらの情報を理解した上で、ビルドしたPX4とQGroundControlを接続させることにしました。

GroundControlのユーザインタフェース仕様は、使いながら理解していくスタイルです。よくわからない中で情報収集しながら、環境設定を行い、PX4との接続確認はできました。

ただ、PX4はシミュレータと接続されていないので何も動きはありませんし、そもそもQGroundControlはどのように操作して、どういう表示ができるのか正解なのかがわかりませんでした…。

そこで、ダミーの通信データを送信するシミュレータ hakoniwa-px4simを作ることにしました。

４日目：hakoniwa-px4simを作る

まだまだ改善ポイントはありますが、hakoniwa-px4simは、以下で公開しています。

https://github.com/tmori/hakoniwa-px4sim

今回、hakoniwa-px4simを作成する上でのポイントは、以下の２点でした。

大量にあるMAVLinkパケットの通信データのエンコーダとデコーダをどうするか
通信プロトコルをどうやって実装するか

１点目については、全世界で利用されているMAVLinkであれば、通信データのエンコーダとデコーダはライブラリがあると思いました。そこで、軽く検索かけたところ、予想通り、github上で公開されているものがありました。

https://github.com/mavlink/c_library_v2

２点目については、シミュレータが利用するMAVLinkの通信データは公式サイトで説明されていました。

ただ、これらの通信データはどのタイミングで送受信するのか、どういうデータを設定するべきなのかの情報が無いという課題にぶつかりました。。

ここでもQGroundControlと同様に何が正解なのかわからないという問題にぶつかったというわけです。

とはいえ、ひとまず、TCP通信プログラムを実装して、PX4からどのようなデータが出てくるのかを観察すれば何か手掛かりが得られるだろうと思い、実装を進めることに。

５日目：通信プロトコルの理解を深める

作成した hakoniwa-px4simとPX4を接続し、PX4から送信されてくるパケットを観察したところ、以下の２つのパケットが来るのみで、ダンマリ状態でした。

COMMAND_LONG
HIL_HEARTBEAT

これを受けて、シミュレータ側からのセンサ情報の送信が必須であるとの仮説を立てました。ただ、どのようなデータを送信すべきか、どのような形式で送信すべきかといった具体的な情報が不足しており、開発の方向性が見えにくくなっていました。

この状況で、開発が停滞することを避けるため、一度開発状況を整理することにしました。全体を大きな視点で見ることで、課題を再確認し、次のステップへの方針を明確にすることができます。（下図）。

図を見て俯瞰してみることで、現在の課題点や将来的な目標が明確になりました。最大の課題として、シミュレータとPX4との間の通信プロトコルの不明確さが挙げられます。この課題を解決すれば、PX4の動作が開始され、QGroundControlを通してもデータの観察が可能になると期待されます。

そこで、既存のシミュレータとPX4 SITLと接続した環境を構築して、流れているパケットをWiresharkで観測し、データの送信順番や流れているデータの設定値を観察することにしました。

今回試したものは、jMAVSimです。

左側が jMAVSimで、右側がPX4です。起動完了後、 PX4 のコマンドで、takeoffを実行するとドローンが上昇することがわかります。

ここまでの通信の流れをキャプチャし、hakoniwa-px4simで再現できれば良いというわけです。

６日目：hakoniwa-px4simでtakeoff!!

そして、Wiresharkで通信データを確認することで、センサデータの代表値と通信周期を把握できました。そこで、hakonwia-px4simからPX4にセンサデータを送信する試みを行いました。

しかし、以下の問題にぶつかりました。

同じセンサ値を送り続けるとPX4が異常検出する
センサデータ値にノイズを入れたデータを作ってみたが、PX4が takeoff 可能な状態にならない

原因がわからないまま・・、数時間様々なトライをしましたが、問題解消できませんでした。

そこで一案。jMAVSimの通信パケットをキャプチャするプログラムを作って、タイミング含めてバイナリファイルに保存する。そして、そのキャプチャしたファイルをPX4に対してリプレイ送信してはどうか？と。

この思いつきから３時間かけて、キャプチャ機能とリプレイ機能を作りました。デバッグ大変でしたが、見事、以下のように takeoff 成功しました！！

PX4との連携が正常にできるようになり、jMAVSimの通信パケットをリプレイして成功することができたのは大きな一歩でした。これにより、hakoniwa-px4simは基本的な動作をするシミュレータとしての役割を果たすことができました。

しかし、これは一時的な解決策であり、実際の動的なシミュレーションのためには、リアルタイムでのセンサデータの生成と送信が必要です。

そこで次のステップとして以下のことを考えています。

センサモデルの実装：実際のドローンの挙動に近似するようなセンサデータを動的に生成するモデルを実装する。
異常検出の原因究明：PX4がセンサデータの異常を検出する原因を特定し、それに対応するセンサデータの生成方法を模索する。
リアルタイム通信の最適化：リプレイではなく、リアルタイムでの通信を効率的に行うための手法やプロトコルの最適化を検討する。

リプレイ機能の実装に成功したことは大きな達成感を得ましたが、まだまだこれから先の課題も多いです。しかし、一つ一つの問題を解決していくことで、hakoniwa-px4simを完成度の高いシミュレータにしていきたいと思います。

最後に

こうして見ると、一つ一つのステップや課題解決には多くの時間と努力がかかっていました。そんな中での開発や試行錯誤を繰り返しながらの日々だったため、ブログの更新が遅れてしまいました。皆さまには大変お待たせしてしまい、申し訳ございません。しかし、このような経緯を通して得られた知識や経験を共有することで、皆さまの何かの参考になれればと思います。今後とも、よろしくお願い申し上げます。