drawtonomy と手書きの OpenSCENARIO XML

手書きの OpenSCENARIO XML

OpenSCENARIO の XML を直接手で書くのは、いまでも普通に通用するワークフローで、多くのケースでそれが正解だ。

XML を直接書く方が向いているのは次のような場面だ。

シナリオが小さく、バイト単位まで自分で制御したい。
DSL やコード生成パイプラインから機械的に XML を出力している。
ビジュアルツールが扱わない仕様 — 条件付きトリガ、パラメータ走査、カスタムコントローラ、複雑な Storyboard、交通流モデル — を使いたい。
シナリオを git で共同管理していて、安定した XML diff を優先したい。

本番のシナリオ作成では、手書き、あるいはコード生成による XML が王道だ。

drawtonomy が今書き出せるもの

エクスポーターによれば、対応範囲は OpenSCENARIO 1.3 の一部だ。

2D 俯瞰の道路ネットワーク (レーン、交差点、シンプルな linestring) を OpenDRIVE 1.8 の .xodr として書き出す (一部のみ)。
車両、歩行者、信号、路面標示を <ScenarioObject> / <Pedestrian> として静的に配置。
参加者の単純な経路を <FollowTrajectoryAction> として出力。

書き出した .xosc は esmini で簡単なシーンを再生できる。出発点として使うものだと考えてほしい。

drawtonomy が書き出せないもの

エクスポーターの roadmap として明示されているものだ。

OpenDRIVE の <junction> 要素。
標識を <signal> として書き出すこと。
加減速プロファイル、停止イベント、信号と連動した経路、車線変更、複雑な multi-actor Storyboard。
条件付きトリガ、パラメータ走査、カスタムコントローラ、密な交通流。

これらが必要であれば、XML を手で書くか、コードから生成してほしい。

現実的なハイブリッド

drawtonomy でレイアウトを視覚的に下書きし、レーンネットワークと参加者の配置を固める。
esmini バンドルを書き出し、単純バージョンが再生できることを確認する。
.xosc をテキストエディタで開き、drawtonomy が出さない部分を手で足していく。
テスト計画書 / 論文 / スライドに載せる図のソースとして、drawtonomy ファイルを残しておく。

drawtonomy は下書き、XML は実体のソース、という分担だ。

同じ OpenSCENARIO コミュニティの中で

手書き XML は OpenSCENARIO の基礎にあたるオーサリングパスで、エコシステムのあらゆるツールが最終的にはそれ (あるいは DSL の同等物) を出力する。drawtonomy のエクスポーター、scenariogeneration、Scenic、RoadRunner、Blender DSC などはどれも、どこかの段階で XML を吐く。XML を直接読み書きする人がいるからこそ標準が標準であり続けるわけで、XML を吐くツール群は、コミュニティが標準のまわりに積み重ねてきた相互運用性の恩恵を一緒に受けている。