今回は、箱庭コア機能の中でも重要な機能の1つである「同期・通信」について解説します。なお、今回については、通信部分に焦点をあてています。(同期についてはまた別の機会でお話ししたいと思います)
箱庭は Simulation Hub(シミュレーションハブ)なのです!
唐突ではありますが、箱庭の開発をずっと続けてきて、ここ最近気づいたことがあります。それは、箱庭コンセプトの実装ゴールの1つは、「Simulation Hub(シミュレーションハブ)」の実現にあると(下図)。
左側が箱庭アセットで、箱庭のインタフェースを通して、箱庭に差し込みすると言う構成です。そこでは、Pythonプログラムでも、組み込み機器でも、Unityでも Unreal Engineでも分け隔てなく繋がることができるのです。素敵な世界ですよねー。
このような世界を実現する上で重要なポイントは、ある程度標準化されているインタフェースが必要になるという点です。そのためのインタフェースが、PDU(Protocol Data Unit)です。
箱庭のPDU(Protocol Data Unit)とは何か
箱庭のPDUは、箱庭アセットが互いに通信するためのデータ単位です。そして、このデータは、様々な通信プロトコルを介してデータ交換されます。
次に、このPDUの実装をどうしようと思ったかお話しします。
まず、箱庭では、独自のデータ形式や通信プロトコルを使うことは志向しておりません。できるだけ使いやすく、わかりやすく、広く使われているものを採用しようと思いました。
また、通信プロトコルは用途に応じて様々なものがあるので、1の通信方式に縛られたくもありません。
そこで、箱庭では、デファクト標準的な通信プロトコルをサポートしていくことにしました。
現時点では、UDP、MQTT、ROS を対応しています。さらに、同一PC内である場合は、共有メモリでの通信も可能です(下図)。
![](https://hakoniwa-lab.net/wp-content/uploads/2023/09/image.png)
ここで、一口にPDUといっても、その内容は様々です。例えば、カメラデータの場合は、画像データであり、バイト配列の塊です。光センサや温度センサの場合は、32bit程度の浮動小数点型になるでしょう。これらのデータはどのように定義してあげれば良いか悩みませんか?
そこで、箱庭では、ROSのインタフェース記述言語に着目しました。ROSには、ROS IDL (Interface Definition Language) というインターフェース記述言語があり、その定義方法はとても簡単です。例えば、EV3のカラーセンサのデータをROS IDL で書いたEv3PduColorSensor.msgのデータ記述は以下のものです。ROSのプリミティブなデータ型を使って、C言語の構造体のように直感的に記述できますよね。
uint32 color
uint32 reflect
uint32 rgb_r
uint32 rgb_g
uint32 rgb_b
なお、ROSには様々なデバイスに対応したデータ型が用意されていますので、既存のROSのデータ型は箱庭でも利用できると言うわけです。
箱庭の通信プロトコル・アーキテクチャ
箱庭では、様々な通信プロトコルをサポートしているとお話ししましたが、具体的的なアーキテクチャをご紹介します。
UDP通信の場合は、下図の構成となります。ここで重要なポイントは、箱庭アセット側では、UDP通信プログラムを書く必要がないと言う点です。単純に、PDUデータの読み書きをすれば良いだけなのです。UDP通信自体は、箱庭側で勝手にやってくれるのです!
![](https://hakoniwa-lab.net/wp-content/uploads/2023/09/image-1.png)
MQTT通信の場合も、UDP通信と同様に下図のような構成となります。MQTTの場合は、MQTTブローカー/パブリッシャー/サブスクライバーが必要となりますが、箱庭側で用意してくれています。
![](https://hakoniwa-lab.net/wp-content/uploads/2023/09/image-2.png)
ROS通信の場合は、下図の構成となります。箱庭では、組込み機器との連携も視野に入れていますので、ROS2 通信の実現では、mROS 2 を積極的に活用しています。
![](https://hakoniwa-lab.net/wp-content/uploads/2023/09/image-3.png)
共有メモリでの通信場合は、下図のようなシンプルな構成です。
![](https://hakoniwa-lab.net/wp-content/uploads/2023/09/image-4.png)
ここまでの構成を見ていただければわかると思いますが、箱庭アセット側のインタフェースはPDUバッファーであり、単純に、PDUデータの読み書きをすれば良いだけなのです。箱庭アセット側で通信プログラムを一切書く必要がないのです!(大事なことなので何回も言います)
箱庭のPDUが切り開く箱庭の可能性
箱庭のPDUの説明は以上となりますが、通信プロトコルとして MQTT や ROS を利用できると言うことは、箱庭は組込み機器との親和性も高いと言えます(下図)。そのため、デジタルツインのような構成も箱庭を使えば簡単に実現できると思います。
![](https://hakoniwa-lab.net/wp-content/uploads/2023/09/image-5.png)
箱庭は、シミュレーションの新たな可能性を切り拓くプラットフォームにしていきたいと考えています。PDU(Protocol Data Unit)を通じて、様々なアセットが簡単に通信し、協力して現実世界の複雑なシステムをモデル化・シミュレーションできるのです。
また、通信プロトコルや組み込み機器との親和性により、デジタルツインの概念も実現できますし、革新的な応用分野での探求が可能になると思います。
箱庭は無限の可能性を秘めたシミュレーションハブとして、新たな挑戦と冒険を続けていきます!
コメントを残す