**********************************************************************
セッションS5-c 分科会１
テーマ：scenario_simulator_v2：完全自動運転のためのシナリオテストフレームワーク
コーディネータ: 片岡大哉(株式会社ティアフォー)
日時：9/3(金) 15:10～16:20
参加人数：約20人
**********************************************************************

・Autowareとは
オープンソースな自動運転システムであり、自己位置推定、認識、計画など自動運転に必要なものすべてが公開されている。
TierIVだけでなくAWF(Autoware Foundation)に加盟している企業によって開発している。
プラットフォーム開発も行っており、TierIVでクラウドやIoTを活用したWeb.autoを作成し、開発の効率化を進めている。
オープンソースであることで誰でも簡単に自動運転サービスに参入できるため、様々なサービスやエコシステムが生まれ自動運転技術が民主化される。


Autowareを開発するにあたってシミュレーションは以下のような大きな役割を持っている。
・デグレの防止
自動運転システムはかなり複雑である。
例えば、Autowareは250のROSパッケージがあり、車載コンピューターの上で数100のROSノードが一斉に動いているためデグレが起きやすい。
そのため、昔はあるケースで動いていたが、現在は動かないといったことがよく起こる。
シミュレーションを行うことによってデグレを防止することが出来る。

・実車試験をするコストの低減
実車試験ですべてをこなすと、くまなくテストすることが不可能である。
例えば、カメラの反応は太陽光の強さによっても変わり、それを自分たちで調整することはできない。
シミュレーションを使うことによって、太陽光なども調整できるため実車コストを下げることが出来る。

・事故リスクの最小化
自動運転システムが事故を起こしてしまった場合、人をひきかねない。このようなリスクを下げる必要がある。
そのため、公道で走る前にシミュレーションでテストすることが重要である。
TierIVではテストを自動化している。
1行書き換えただけでも、変更をプッシュするとテストが行われ、その変更を行っていいのか判定が出る。



TierIVでは2種類のシミュレーションを行っている。
・ODD類別型ユースケース検証
こちらは事前に決めたシナリオを走り切れるかテストする。変数も設定でき、一度書けば一斉に検証が出来るようになっている。
ODDとはOperational design domainであり、その運転車両が運転する交通量、天候、道路状況、地形、車両、時間帯などの環境を定義している。
それらからテストケースを決めている。
TierIV safety reportにODDについて詳しく書かれている。

・ランダム検証
上のテストケースは人間がやるべきことを定義しているので、抜け漏れが発生している可能性がある。
それに対してランダム検証は簡単なルールを条件に自車両以外のNPCを大量に出しテストを行う。
ここで問題が発生した場合は、仕様に問題があるかどうかを議論して、仕様かシミュレーションの間違っている方を直す。



シナリオテストのpain pointであり、v2で改善されている項目について。
・膨大なテストケースがある
現在100、1000の単位でテストケースがあり、これからも指数関数的に増えていく。
それらの膨大なテストケースを人が検証するのは非効率である。そのため、自動的にテストを行うが、結果が変わってしまう場合は信用できない。

・完璧なシミュレーターが存在しない
全てのセンサ、ECU、車両の運動を完璧にシミュレーションできるシミュレーターは存在しない。
全てのテストケースを満たすには複数のシミュレーションに対応する必要がある。
同じシナリオを他のシミュレーターで使用する際に手動で書き換えなければいけなくなるが、非効率なのでCo-simulation modelを採用した。
Co-simulation model はNPCの挙動を制御する部分とそれ以外の部分に分割した。これによって一度書けばシミュレーターが変わっても書き直す必要が無くなっている。

・シナリオ言語はResearch Area
どのようにシナリオを記述するのかが良いのかは誰も分かっていない。
現在研究が行われており、数年以内に最終的な答えが得られるものではない。
そのため、複数のシナリオフォーマットをサポートした。交通流シミュレーターを共有ライブラリとして実装し、それをラップする。

・シナリオが冗長
シナリオの中にでてくるNPCはかなり細かく指示を出す必要がある。そのためシナリオが長く、冗長になってしまう。
この問題を解決するために自動運転技術をNPCロジックに対して適用した。
これにより最低限の指示で道路交通法を守りながらシナリオの指示を受けて動くNPCを実現した。

・テストツールの信頼性
NPCロジックに機能追加を行うとデグレが起きやすい。
フレームワークへのソースコード変更を含む変更には単体テストだけでなく結合テストも行っている。


これらすべてを考えたことでできた設計コンセプトは、以下のようになっている。
・可能な限り決定性を担保
ROS2に依存しない部分はすべてフルスクラッチで実装、決定性の担保を実現している。

・全てのパーツをプラガブルに
シミュレーター、シナリオフォーマットはあとから変更、追加が可能になっている。

・オープンソース
オープンソースにすることで世界中誰でもcontributionが可能になっている。


各要求仕様に対する設計と実装
・決定性
決定性とは同じテストケースの実行結果が確実に同じになること。
ノードとノードを切り、トピックで繋ぐ方法はやりやすいが、ROS2はUDPベースのプロセス間通信であるので、パケットの到着順保証はない。
ROS2を使う限り決定性担保は不可能になっている。
そのため、全てのコアロジックをシングルプロセスなノードとして実装することでコアロジックを決定的にする。
この先に繋がっているシミュレーターも決定性が担保できれば決定的であると言える。

・Co-Simulation Modelの採用
センサモデルだけでも雨天時のLidar noise model、フリッカー減少、ローリングシャッターなどの対策が実装されており、性能に関わっている。
ただ、これらをシミュレーションするのは難しい。
効率が良いと言われている方法が2つある。
・Game-Engine Based approach
いろいろなシミュレーション開発ツールがある。リッチで早く、きれいなシミュレーションが出来る。
・Data-Driven approach
最近機械学習方面で出てきた解決策。機械学習でフィルタを通す手法などがある。

問題
前者の方法は複雑なノイズモデルシミュレーションや点群ごとの時間のずれを厳密に行うことは難しい。
後者の方法はモデルがブラックボックスになってしまうため、シミュレーションの妥当性担保には先にモデルのvalidationが必要になる。
完全なリアリズムを持つシミュレーターはなく、必ず長所と欠点がある。
解決策として、複数のシミュレーターを使い分けて適切にテストケースを設計、協調動作させることで「write once run anyware」を実現している。


・シナリオ言語はResearch Areaで乱立状態
フォーテリックスという会社が作っているシナリオ言語はプログラミング言語のようになっている。
これを使って実際に動かしている動画がYoutubeにあがっている。
これを使って複数のシナリオを混ぜることも出来る。

2019年に出たジオシナリオという論文もシナリオ言語を出している。
コンクリートシナリオと呼ばれるものであり、少し効率は落ちる。

ドイツの研究所もシナリオ言語を出している。シナリオを書くと自動的に道路などを自動生成する。


なぜこんなに乱立しているのか？
自動運転システムのvalidation方法を確立している人がいないから。それぞれの手法にそれぞれの良さがある。
すぐに一つの言語ですべてをまかなうのは不可能である。そのため1つの手法にロックインされるのは危険である。
1つだけ選んでしまった場合、それがあるケースで使えなかった場合に対応できない。


ロボット技術導入によるNPC高速化
NPCのルートは今までCartesianで指定していた。コンピューターから見ると分かりやすいが、x,y,z座標などで行っているため人間が見ると分かりづらい。
レーンに沿ってゆがんだ座標系の上でNPCの配置や動きを定義可能にした。より直感的なNPC行動記述を実現できている。
NPC行動はルートを指定速度で追従するのみで分かりづらい。これだとなぜ加速したのかなどの理由が分かりづらい。
Behavior TreeベースのNPCロジックを構築した。単純な状態機械より状態が増えたときに開発が難しくなりづらい。
状態を追加することで新たな行動を追加することが簡単にできる。

これらにより少ない記述量でNPC効率的に動かせるようになった。


テストツールの信頼性向上
単体、結合テストをPRごとに実施している。
依存パッケージ更新でツールが動かなくなるのを防止するべく毎日テストを実施している。
新規開発者の参入障壁をへらすためにドキュメントも自動生成している。


全体アーキテクチャ
Simulation APIはコアの交通流シミュレーターである。これが、Zeromqとprotobufを使って他のシミュレーターとプロセス間通信を行っている。
Autowareの様々なバージョンに対応するためAWAPIを使いAutowareを抽象化し、立ち上げ動いているかを常時検証する。
次に、AWAPI AdaptorがAutowareと通信を行う。
Aimulation APIの中にあるEntity Managerが本体である。自車両のダイナミクスシミュレーションをするものなどが入っている。
インタプリタ全体をモノリシックなバイナリで構成し決定性を担保している。
Simulation APIにNPCロジックや座標管理などコア機能すべてを詰め込んでいる。
シナリオ解釈器は共有オブジェクトについているC++のAPIをつかって動いている。そのためシナリオ解釈器は変えられる。
Simulation APIは任意のROS2 componentに紐づいているので新しいシナリオフォーマットを構築することも簡単にできる。
道路交通法から見て合法な動きが出来るようになっている。
各NPCの3次元座標を全て持っている。
Unityベースなど様々なシミュレーターと繋がれるようにしているSimulatorは入力に対して決定性を持つ。


Scenario_simulator_v2のアーキテクチャ
Lidarが止まった際にしっかりと失敗を出すかどうかのテストなども行っている。
Workflowに出されたシナリオはxmlに変換する。xmlは人間には読みづらく冗長。
TierIVでは独自形式をyamlにしたものを追加し、それを読めるようにしている。
これをコンクリートシナリオとして出し、インタプリタに読み込ませることで実行する。
これによりテストランナーはworkflow fileに記述されたテストケースを全て実行し、結果が予想通りかを検証する。


まとめ
オープンなシナリオテストフレームワークを紹介した。
複数のシミュレータ、シナリオ言語をサポートしている。
自動運転システムを応用したNPCロジックも搭載されている。
全体アーキテクチャの紹介も行った。
githubのリンク
https://github.com/tier4/scenario_simulator_v2


今後の展望
北京、インドのデリーなどの複雑な交差点をシミュレーションする論文が出ている。
この論文では線形再起化によってNPCを動かしている。軽快かつ賢く動作している。
効率よく交通量を流し、NPCを賢くふるまわせている。
これがうまくいけばNPCがさらに複雑な状況下でも適切に行動可能になる。
将来的には左折時に割り込むバイクや自転車のテストも出来る。


メンバー募集中
・NPCプランナー開発
・微分幾何
・数理最適化
・シナリオ解釈器開発
・プログラミング言語開発
・抽象シナリオ


質問
Q. インタプリタも完全に自前で実装しているのか？
A. そう。もしこれが決定性を担保できない場合、全体の決定性を担保できないので自前で実装した。

Q. 欧州にも同じようなものがあるがどうか？
A. 実際に調査を行ったところ、相性の悪さなどから自分たちで書くしかないと感じた。

Q. 何年前からのプロジェクトか？
A. 去年の7月から片岡さんともう一人の2人体制で開発を行っている。

Q. シミュレーションの部分だけを持ってきて、別のシミュレーターにつなげるという話はあったが、
インタプリタだけをもってきて、交通流の部分から別のシナリオとつなげられるか？
A. 出来る。

Q. 交通流シミュレーションの間のインターフェイスなども標準化されているのか？
A. 交通流シミュレーターのためのものがあり検討したが、オープンシナリオ実装しきって、そこからブラッシュアップしようという話になった。
最近はオープンシナリオ2.0なども出てきて、何が良いのか分かりづらい。

Q. シナリオの書き方がプログラミング言語が考えなければいけないところである。
例えばPythonライクだというものがあったが、どういうものがあればうれしいなどはあるのか？
A. おそらくRのようなタイプのデータサイエンティスト向けの言語になると思われる。
効率よく再現性をもつように書ききるのが大事なので、パッケージ管理システムを備えたシナリオ記述専用の言語が出来上がるのではないか思っている。

Q. 並行した動作を多く書くとなるとRとは違う概念が必要ではないか？
A. 論文で出した理論で解決する方法がある。リアクティブプログラミングを導入することで解決する。
ただ、読みやすいかどうかは疑問点がある。
さらに、最終的にデータサイエンティストがテストケースを作るようになった場合、言語を生で書くのかは疑問符が付く。
IDEのようなものを作る必要があると思っている。
そのUIを同設計すれば良いかという問題がある。
GUIが嬉しい気もするが、テキストで書きたい要望もある。どう設計すれば効率が上がるか分からない。
モデルベースも考えられる。

Q. アーキテクチャなど大変だったろうが、何人月のプロジェクトだったか？
A. 2人×12か月なので、24人月のプロジェクトだった。
Autowareの3分の1程度で、3,4万行のプログラムになっている。

Q. とりあえず動かしたい場合、最小セットはどうなっているのか？
A. デモを動かせるチュートリアルがReadmeに用意されている。
Build instructionという項目があるので、そこにあるSimple demoを動かすと、交通流がシミュレーションできる。
Autowareと組み合わせるときは手間が必要なのでTierIVに聞くのが良い。
このシミュレータはAutowareとは切り離して単独で動くようになっている。
一緒に動かすためにはひと手間挟む必要がある。
現在サポートしているのはproposal版にカスタムを入れたバージョンで、auto版もサポートしているが、ドキュメントの整理などはもう少し待つ必要がある。

Q. カルラなどを一緒に動かすことはできるか？
A. 出来ていない。Zeromqとprotobufを作りきる必要がある。
現在はUnityベースのシミュレータの上に実装を行っており、動きを確認している状態なのでこれからカルラやsvlなどに簡単に使えるライブラリなどを用意する予定。

Q. どこまでAutoware dependentなのか？
A. 完全にdependent。
Autowareを立ち上げられるようにしているが、architecture proposalとautoしかサポートしていない。
Q. independentにするつもりなのか？
A. するつもりはない。
もしそうしようとすると、立ち上げプロセスなどを抽象化する必要があり、その部分に工数を使えないと判断した。


片岡さんが聴講者に聞きたいこと
自動運転のvalidation方法
言語というより自動車の自動validationだと何か知見を持っている人が聴講者にいそう。


Q. NPCが交通ルールを守る場合想定外のシナリオは試せないのでは？
A. あえてルールを無視するようにも出来る。
例えば、制限速度を無視する事や、他の車が前にいても止まらないようにも出来る。


Q. 公開されている情報はあるのか？例えば、Behavior Treeなどが公開されているのか？
SWESTに参加していない人に共有できるかどうか？
A. 以前発表したので、ロボセミ　で検索すると資料が出る
7月16日
https://robosemi.connpass.com/event/216997/