**********************************************************************
セッションS1b
テーマ：「箱庭」でなにができる？最新動向をキャッチアップしてこれからを語り合おう
コーディネータ：森 崇 氏 (永和システムマネジメント)
　　　　　　　　高瀬 英希 氏 (東京大学／JSTさきがけ)
日時：2021/9/2 19:30～21:00
参加人数：15名（終了時）
**********************************************************************

このセッションでは、箱庭WGが作った成果に対して皆さんのバックグラウンドをお聞きしながら、
最新動向をキャッチアップして、これからの箱庭WGが目指す方向性に皆さんの意見を反映していきたいと考えています。

～参加者アンケート～
・「箱庭」をご存じですか？
扱ったことがある(3/8)
知っているが扱ったことはない(3/8)
初めて知った(2/8)
・去年参加しましたか？
参加した(1/8)
参加していない(7/8)
・何かシミュレータを使っていますか？
ほとんど使っていない(3/8)
たまに使っている(3/8)
よく使っている(2/8)

<「箱庭」の概要 >
IoTのような複雑なシステムは様々な分野の技術を横断している。
そのようなシステムを実証実験の場で一気に結合すると様々な問題が出る。
IoTサービスを構築する際の問題はサービスを開発する視点とシステムを開発する視点に分けられる。
サービスを開発する視点ではどんなサービスを求められているか検討すること自体が難しい。
結合テストはシステムを開発する視点の問題である。
これらの問題の解決を目的とするのが「箱庭」である。
箱の中に皆さんの成果物を持ち寄って各技術者が自分の視点で実証実験できるようにするイメージである。

TOPPERSの箱庭WGとしては、全体結合シミュレーション環境を構築したいと考えている。
可視化技術やクラウド技術は既存のものを活用する。
「箱庭」の想定使用者はシステム開発者とサービス提供者としている。
これにより、サービス要件の早期キャッチアップや改善要望の早期リリースにつながると考えている。
また、箱庭で使うアセットの開発者とコラボレーションできる枠組みも作っていきたいと考えている。
箱庭のコア技術はアセット管理、スケジューリング、同期・通信、時間管理としている。
物理シミュレータやマイコンシミュレータ、自動化ツール、可視化ツールなどを必要に応じて後付けできるようにしている。
単体ロボット向けシミュレータを最初にリリースした。
今年の初めまでにDockerを用いて2ステップで環境構築し、4ステップで実行できるようにしている。

(I氏)2ステップはコマンドか？
　Dockerのコマンドです。
(A氏)Dockerで構築される環境はどんなものか？
　ロボットの制御プログラムはカスタムできる。環境のカスタムは難しい。


< 昨年の分科会のご意見・ご提案に対する対応 >
昨年の分科会では箱庭の今後のビジョンを決めるために、集まった開発現場、教育現場、研究現場の方たちに箱庭を使いたいシーンや箱庭に期待したいことをディスカッションして開発項目化した。
ハード依存の教育演習へのハードルの高さや環境構築の手間、開発者間のコミュニケーション・ギャップなどに困っていた。
箱庭への要望としては、CI/CD環境の構築や箱庭アセットの拡充、デバッグ機能の充実などが挙がった。
WGでできる範囲から実現してきた。
Dockerを用いて環境構築の手間を減らし、ハード依存の教育演習へのハードルを下げた。
組込み開発の環境構築の手間への対応としては、athrillのdebパッケージ化やクラウドのIDE環境の使用を検討し、協力企業が作成中です。
開発者間のコミュニケーション・ギャップへの対応としては、モデリングを活用することで改善できると考え、モデリングと箱庭の親和性向上のための構想を検討中です。

昨年は単体ロボット向けシミュレータのDocker化、箱庭コア技術の再設計と整備、箱庭アセットのシステム構成をAstahで記述、箱庭通信データの可視化を行いました。
また、走行環境の自動生成ツール整備やROSへの対応、クラウド連携の強化を行っている。

< ディスカッション >
自己紹介も兼ねて開発対象のドメインを教えてほしい
(S氏)教育関係の仕事
(A氏)車載OSの開発をしている
(I氏)マイコン用ソフトやラズパイをいじっている、ETロボコン参加の際に箱庭のお世話になっている
(I氏)大学生
(K氏)大学生でAutowareが研究対象
(S氏)労働安全性に関する仕事をしている
(A氏)自動車関連、東京都ETロボコン実行委員会に参画
(O氏)ROSやROS2にFPGA導入する方法を研究
(K氏)工場内のIoT関連をやっている
(K氏)自動運転のシミュレーションをやっている

(高瀬氏)
組込み関連が多い印象でシミュレーションを触っている人が多い。
シミュレータの選ぶ時の観点・使いたいシミュレータはどんなものですか？
(K氏)
ケースバイケースで効率性を重視して複数のシミュレータを使い分けている。
(F氏)
ソフトウェアよりの人間から見て、シミュレータが信用できないならば、状態遷移の確認だけで他は実機で調べたり、ROS bugを使うので、どこまで信用するかは重要な観点である。

(高瀬氏)
箱庭では、観点をカスタマイズして細かいところを見たいときに見られるようにしたいが、現状ではまだできていない。
細かいところをしたいときにシミュレータを使いたい場面があるかどうか？
森さんが最初にAthrillを作った際に細かいところをテストしたかったのか？
(森氏)
v850のOSを移植して欲しいって要望から始まった。
v850のデバッカをもらえず、エミュレータ作成の為にAthrillを作った。
エミュレータ上で論理的に命令を再現して動くものが必要。
論理的な命令は再現できていた。そういったものがあるかどうかが大事。

(高瀬氏)
どこまで細かいところをシミュレータでやるか？
(森氏)
その人の課題にあった精度のシミュレータを使えばよいと考えている。
全てに万能なシミュレータはコストがかかるだけで意味がない。共通項を「箱庭」で作れるかはまだ自分の中で答えがない。

(高瀬氏)
コアなところを提供してニーズに合わせてカスタマイズできたら楽しい。
シミュレータにどのようなことを期待して使っているか？
(K氏)
実環境でやると危ないことを行う際にシミュレータを使う。
特に人型ロボットや自動運転では、多額の損失を防ぐために必要。
(O氏)
機能を確かめられれば良い。簡単に動かせたり、動作が軽いほうが良い。

(高瀬氏)
楽しいところに最短経路で行けるのはシミュレータや仮想環境の嬉しさかなとは思う。
(O氏)
若者はゲームに慣れているから、ゲームぐらいのもので良いのか。
そうすると、Unityはちょうど良いのかな？Unityを触っていないので分からないけれども。
(高瀬氏)
Unityだからゲームってわけではないが、GUIがおしゃれなほうが触る印象がある。
(O氏)
最初のコンセプトでいろいろな分野の人が共通して使えるものにしたいとのことなので、おしゃれなGUIは大事かなと感じました。
(A氏)
業務のシミュレータは他の人と同じ観点で選んでいる。
ETロボコンのほうのシミュレータは参加者がETロボコンに参加している気になるものを選んでいる。
現実と合っていなくても良い。実現したいことがあってそれにあったシミュレータを作ったり使ったりしているのかなという印象です。
過去のETロボコンで走行体ができた動きは全てできるようにしていた。
Unityも万能ではない。
ゲームだと予期せぬ動作を抑える手段もあるが、ETロボコンではその抑えにも限界がある。責任の所在が分からなくなる。
(K氏)
シミュレータの開発の際はCIを入れて欲しい。すぐに変なところから依存が注入されてしまう。

(高瀬氏)
今の話はシミュレータ自体が依存するので辛いということだと思うが、嬉しい部分は関連するライブラリの更新が現実世界でも反映しているか確認できる。
環境を気にしなくて良いのは、組込みでは結構メリットになる。
(A氏)
環境面の話では、物理環境以外に開発環境の問題もある。
今は少ないが、昔はバージョンが0.1上がっただけで動かなくなることがあった。
(K氏)
ゲーム業界ではバージョンをフィックスして2,3年は同じ環境で開発する。
その後、お試し部隊が手分けして動くバージョンを探し出し、見つけたバージョンに入れ替える。

(高瀬氏)
シミュレータは出来上がりを提供するパターンが多い。
組み込みのシミュレータではそういうものがない印象がある。
(K氏)
ライブラリを使うかどうかっていう問題がある。
自分は自分で作らないと信用できない。使うとしてもテストでバリデーションされたものしか使わない。
シミュレータで重要なことは何回やっても結果が変わらないこと。そうじゃないと運用が辛い。
それを避けるためには自分でフルスクラッチするか、信用できるライブラリをバリデーションしたうえで持ってくるしかないのではないか。
(A氏)
アセット系は他所のものを入れるとリスクが跳ね上がるので、自分で作りたいっていう気持ちは分かります。
開発時間の都合でブランチを切る場合もある。

(高瀬氏)
開発者の視点が増えているので、使用者の視点も聞きたい。
シミュレータを使うときの気持ちや他のシミュレータの使いやすいところとか足りないところはありますか？
(I氏)
EnPitで使った際に、事故っても一瞬で戻せるのは良かった。
ハードでは配線のやり直しや部品の買い替え交換が必要になるときもある。
ただ、いろいろな機能を求めると、部品を買いそろえて付けることができないのはいつもと違った。
(高瀬氏)
切って張っての作業はシミュレータはやりやすい。
(K氏)
講義や実験でシミュレータを使うことはあまりなかったが、Autowareのシナリオのシミュレータは使ったことがある。
NPCの車の動きを設定して自車の動きを見られる。いろいろな条件を簡単に変えられるのは便利に感じている。

(A氏)
「箱庭」はCPUの命令レベルまでシミュレーションの対象に含まれているのは画期的でレアだと感じる。
Unityの中にネイティブライブラリかなんかが読み込まれているんですよね？
(森氏)
CPUシミュレータをLinuxのプロセスで動かしてUDPで通信させている。
(A氏)
それだと結構移植もやりやすそう。
ただ、UDP通信は遅いので、本気で使うならば見直さないとダメですね。一般論で言うとROSを使うっていう方法もある。
(森氏)
「箱庭」は通信方式をいろんなバリエーションにしたい。
いろんな用途に使ってもらえるところを目指したい。
K氏に評価していただいたこともあるが、「箱庭」のコンセプトの1つにシミュレータの仮想化レベルを変えられることがある。
(K氏)
それはとても重要だと思っている。自分もそこを切り替えるためにひたすら同じシミュレータを作っている。
完璧なセンサシミュレータと完璧な物理演算を持ったシミュレータは両立しないと思っている。

(A氏)
今GitHubで公開されているUnity環境のアセット部分は公開されていないのか？
(高瀬氏)
Unityを配る方法に困っている。
(A氏)
大部分がC#のスクリプトでモデルとかが入っていない。
(森氏)
Unityのパッケージを個別に提供している。そのあたりがまだ整理しきれていない。
(A氏)
ユーザとして環境構築しようとした際にアセットの公開場所が分からず、心が折れた。
Dockerでどこまでできるのかの質問がここに通じている。
(高瀬氏)
ご要望はすごくよく分かる。
(森氏)
A氏が触った時から相当ソースが変わっている。ROSとかの導入により抽象度が上がっている。
(A氏)
アセットの入れ方がチュートリアルとして整備されれば、コンセプトどうりにロボットをどんどん入れたり置物を置いたりしやすくなる。
(森氏)
コンセプト動画を作成したが、この手順をユーザレベルでできるようにしたい。
次のパッケージではこれをお手軽に試せる環境を、と考えている。

■まとめ
(F氏)
プロユースの話や学生の話のどちらも聞けて、IT側の人間がこの分野で活躍していくためには便利な点を分かるようにちゃんと説明していかないといけない。
その点でまだまだ弱い。

(森氏)
「箱庭」は３年前に立ち上げて、あまり評価をいただいていない中で徐々に進化している状況です。
もともと「箱庭」でやりたかったコンセプトはクラウド環境で自分の成果を持ち寄って、同じ画面でシミュレーションをして実証実験なしでできることを目指したい。
問題を乗り越えてうまくできるようになっていこう、という夢を描きたかった。
いろいろな問題があるが、皆さんのような優秀な方がいれば乗り越えられると思うので、これからも協力いただけるとありがたいです。