こんばんは〜。あー、今日も日が暮れちゃいましたね。
だんだんと、日が落ちるのが早くなりました。

箱庭ドローンv3.4.0、今日のお題は？

昨日は、MuJoCoについて語りましたので、今日は何を話しましょうか。

ところで、
話変わりますが、実は、今日、箱庭のプログラムのバグを２件見つけました。

１つは、OSS側の箱庭PDUのPythonライブラリで、バイナリ変換周りで結構嫌なやつに出会いました。
ちょっとした思いつきだったんです。

「軽く、動作チェックでもしてみようか」

そう思い立ち、ほんとに軽い気持ちでやったんです。そしたら、….

なんか、おかしい
データ読めない？
設定ミス？
いや、あってる…。
あれ、もしかして…、
エンコーダーのバグ？しかも可変長配列のむずいやつ？
：
まじ？

「あー、みてしもた。」

朝イチで始めた、ほんのちょっとした気まぐれでした。
なのに、、、毎日楽しみにしている朝ごはんは、お通夜のようでした。

でも、ちゃんと直しました。ノートに絵を描いて、
この条件だから、ここにこのデータがあるはずなのに、
「あ、ここない。」
だから、ここ直すのね、はい、１時間かけました。

話が逸れました

今日は、箱庭環境シミュレーションのリリース前テストをやろうとしていたのです。
なので、この話をしようと思っていたのでした。

環境シミュレーションを真面目に考え始めたのは、先日のブログで少し取り上げてたやつです。
吉次さんと、

「いつか、箱庭ラボのブログで、粘菌と箱庭ドローンをテーマにした連載記事を書こう！」

って約束したのを、少しずつ、箱庭としてどうやったらよいか考えなから、
アイディアや技術を温めてきました。

マーケットインではなく、約束インですかね。

箱庭環境シミュレーション

これまで、箱庭の環境シミュレータは、箱庭アセットとして、
箱庭ドローンのリポジトリ内の１つのプログラムとして作ってきました。

でもねー、これじゃだめなんですよ。

「なぜか？」

環境シミュレーションは奥が深い。
平たくいうと、環境って、「自然環境」、「物理環境」、「電波・通信環境」なんかがありますよね。
さらに、それらの環境上でシミュレーションとしては、何を目指すべきなの？その目的は？
で、それを色々絵を描きながら、考えました（下図）。

でも、なんか足りない、これだと、ただやっただけになちゃう。

で、ようやく自分なり辿り着いたそのシミュレーションの目的、それは、

現実を再現するためではなく、現実におき得るリスクを考察・体感し、
もしのリスクを自由に設定して、頑健な設計と円滑な合意形成を目指すこと

でした。
（じっくり、１ヶ月くらい、ねかせながら、ぼやぼやと考えながら、ここに行きつきました）

つまり、これらのコンセプトは、単なる１プログラムに収まるはずがないんです。

だから、新しいリポジトリを作りました。

https://github.com/hakoniwalab/hakoniwa-envsim

環境シミュレーションのアーキテクチャ

最初に頭に浮かんだのは、「神戸港」でした。
あの広い港の上空を、箱庭ドローンが風に揺れながら荷物を運ぶ——
そんなシーンを、まず“想像”したんです。

きっと、そこには風の影響もあるし、電波が届きにくい場所もある。
GPSが乱れることだってあるでしょう。
でも、それを「実際に試す」には危険もコストも大きい。
だったら、箱庭の中で、現実に起こりうる“環境リスク”を自由に再現できる世界を作ればいい。

そう思って、地図データをベースに環境情報を埋め込もうとしました。
けれど、やってみるとすぐに限界に気づきました。
広大な神戸港の地図に、風・温度・電波などの細かな情報を手で入れていくなんて——到底、無理。

そこで登場したのが、このアーキテクチャです。

環境データを 「作る」(Creator)、「見る」(Visualizer)、「探す」(FastSearcher)、
そしてそれを 「使う」(シミュレーション) という４つの要素に分けました。

• Creator は、環境を“描くための道具”
• Visualizer は、“見える化して考えるための道具”
• FastSearcher は、“効率的に活用するための道具”
• Simulation は、“それらをつなげて命を吹き込む存在”

こうして、「環境を再現する」ではなく、「環境を創造する」ための仕組みが生まれました。

こんなのです

こうして、「環境を再現する」ではなく、「環境を創造する」ための仕組みが生まれました。

そして、これが——
Creatorで作成して、Visualizerで可視化した「神戸港の環境マップ」です。

この図の赤い部分はGPS信号が弱くなるエリア。
港湾の構造物や高層ビルの陰影が、そのまま電波の“地形”として浮かび上がっています。
さらに、黄色の矢印は風の流れ。
まるで港全体が“息をしている”ような、そんな感覚を覚えました。

やってみた

論よりRUN!です

ArduPilotで飛行させ、Unreal上でその様子を可視化してみました。

港の上空を、三角軌道で1.5km飛行するテストを行ったのですが——
これが想像以上に“風の影響”を受けました。

テスト結果は次のとおりです。

風あり：走行時間：5分45秒
風なし：走行時間：4分23秒

たった数m/sの風でも、航路全体の飛行時間が1分以上も変わる。
これ、まさに「環境がミッション結果を左右する」ことを、数字が語ってくれた瞬間でした。

こういう差を“再現”できることが、箱庭環境シミュレーションの面白さだと思っています。
現実を模倣するのではなく、現実に起こりうるリスクを感じ取るための装置として。

２件目のバグ

ところで、
話変わりますが、今日見つけた２件目のこと…

そう、今日は朝イチでお通夜の気分から一転して、仕事をガリガリ済まして、
そう、ちょっとした思いつきだったんです。

「久しぶりに、Unreal EngineとPS4コントローラの組み合わせで箱庭ドローンを操縦してみよう」

夕暮れ時、気晴らしの出来心でした。

Unreal Engineは、PS4コントローラ認識させるの難しいのわかってたから、
箱庭PDU通信で、Windows側からPS4コントローラの操作値を送信する仕組みを昔作っていて、
久しぶりにそれを動かして、今日の仕事納めとするかと。

「そんな軽い気持ち、きっとみなさんにもありますよね？」

もうわかりますよね、はい、「エラー」です。動きませんでした。

「あー、みてしもた。」

あー、なんでー？

見てしまった以上は、やるしかない。（そういう性格なんです）

原因見つけるのに、１時間。直すのに１時間。ほんと、つらい。。

夕暮れどきに始めた、ほんのちょっとした気まぐれでした。
ささっと終わらせて、箱庭ブログでも書くかーって思っていたのに、、、

最後に

それでも、がんばってブログ書きました。えらい！

なんども、悪魔の囁きがありました。

「今日は、こんなにいろんなバグに遭遇して、こころ折れたから休みなよ〜」

「もう明日にもちこしなよ。きっと、誰も読まないよ、こんなブログ」

でも…、約束だから。書きました。

今日も、箱庭はちゃんと動いています。
(でも、また、明日とは言いません。きっと辛くなるから）

おしまい。