drawtonomy と手書きの OpenSCENARIO XML

手書きの OpenSCENARIO XML

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

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

シナリオが小さく、バイト単位まで自分で制御したい。
DSL やコード生成パイプラインから機械的に XML を出力している。
drawtonomy が出力しない仕様の機能が必要 — パラメータ走査、カスタム / ML コントローラ、密な交通流モデル、OpenSCENARIO 1.3。
新しい道路ネットワークを junction 込みでゼロから構築していて、本番品質の <junction> ジオメトリが必要な場合。drawtonomy の junction 出力は、インポートした未編集の .xodr を持ち越すときは正確ですが、手描きのレーンから新規に junction ジオメトリを生成するのはまだ精度が低いです。
大規模なカタログを git で共同管理していて、バイト単位で安定した XML diff が重要な場合。

これらの場面では、手書きまたはコード生成による XML が王道です。一方、単一の具体シナリオを作成・実行するだけ — Action、Trigger、PASS / FAIL 判定まで — であれば、ビジュアルエディタの方が通常速く終わります。

drawtonomy が今表現できること

OpenSCENARIO 1.2 向けのビジュアルエディタで、キャンバス上で Storyboard 全体を作成し、XML を一切書かずにブラウザでそのまま実行できます。

2D 俯瞰の道路ネットワーク — レーン、交差点、linestring — を OpenDRIVE 1.8 の .xodr として書き出せます。あわせて車両・歩行者・信号・路面標示をエンティティとして配置できます。
完全な Storyboard: Phase (Act)、Event、仕様にある 35 種類の Action すべて (速度変更、車線変更、テレポート、軌跡追従、コントローラ切り替えなど) と、19 種類の Trigger 条件 (プラス advanced 6 種) を AND / OR ロジックで組み合わせられます。
END / FAIL 条件によって、シナリオ実行時に PASS / FAIL 判定を出せます。
WebAssembly にコンパイルした esmini によるブラウザ内実行 — トランスポートコントロール、フレーム精度のシーク、追従カメラ、Ghost 軌跡、そして任意で再生を確認できる 3D プレビューを備えています。ページを離れずにシナリオの実行結果をレビューできます。同じ .xosc は、そのままネイティブの esmini でも実行できます。
OpenSCENARIO 1.0・1.1・1.2 へのエクスポート (1.3 はまだ未対応) と、OpenDRIVE の <junction> / <connection> プリミティブ、標識を <signal> エントリとして出力できます。

drawtonomy が表現できないこと

いまも手書き、またはコード生成による XML が必要な、正真正銘のギャップです。

OpenSCENARIO 1.3 のエクスポート — インポートには対応していますが、エクスポート先としてはまだ提供していません。
ゼロから道路ネットワークを組み立てる際の、本番品質の OpenDRIVE <junction> ジオメトリ。インポートした未編集の .xodr を持ち越す場合、junction の接続関係は正確にラウンドトリップしますが、手描きのレーンから新しい junction ジオメトリを生成するのはまだ精度が低く、解析的なクロソイドジオメトリはモデル化されません。
パラメータ走査、カスタムまたは ML ベースのコントローラ、密な交通流モデル。
OpenSCENARIO 2.0 / M-SDL (drawtonomy が対象にしているのは 1.x です)。

これらが必要であれば、XML を手で書くか、コードから生成するのが今も正しい選択です。

現実的なハイブリッド

drawtonomy だけで作成・実行が完結するシナリオがほとんどで、その場合はブラウザが唯一の正とみなせます。手書き XML が必要になるのは、その外側にある限られた場面です。

レーンネットワーク・登場物・Action・Trigger・END / FAIL 条件まで、シーンと Storyboard を drawtonomy 上で作成し、実行して判定を確認する。
drawtonomy が出力しない仕様の機能 (junction プリミティブ、パラメータ走査、カスタムコントローラなど) が必要になったら、.xosc を書き出し、その部分だけ手で編集するかコード生成する。
大規模なカタログをまたいでバイト単位の git diff が欲しい場合は、正となる XML はコード側で管理し、drawtonomy は個々の具体シナリオの作成・レビュー・再生に使う。

drawtonomy はシナリオを作成・実行する場所であり、手書き XML はまだ手が届かない仕様の隅を埋める逃げ道として残ります。

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

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