drawtonomy 與手寫 OpenSCENARIO XML 的比較

手寫 OpenSCENARIO XML

手寫 OpenSCENARIO XML 是一種常見的工作流程,對許多使用情境來說也是正確的選擇。

以下情況適合走 XML 這條路：

場景規模小,你想要位元組級別的精確控制。
你正透過 DSL 或程式碼生成流程,以程式化方式產生 XML。
你需要 drawtonomy 尚未輸出的規格功能——參數掃描、自訂 / ML 驅動的控制器、密集交通流模型、OpenSCENARIO 1.3。
你要從零開始建構含路口的新道路網路,並且需要生產等級的 <junction> 幾何——drawtonomy 的路口匯出在「原封不動延續匯入的 .xodr」時很準確,但從手繪車道合成的新路口幾何目前精度還不夠。
你透過 git 協作維護大型 catalog,穩定的位元組級 XML diff 對你很重要。

在這些情況下,手寫或程式碼生成的 XML 是標準做法。若目標是編寫並執行單一具體場景——action、trigger,以及 PASS / FAIL 判定——視覺化編輯器通常更快。

drawtonomy 目前能表達的內容

一款針對 OpenSCENARIO 1.2 的視覺化編輯器,可在畫布上編寫完整故事板並在瀏覽器中執行——完全不用手打 XML：

一個 2D 俯視道路網路——車道、路口、線串——匯出為 OpenDRIVE 1.8 .xodr,並可放置車輛、行人、紅綠燈與道路標線作為場景實體。
完整的故事板：階段(act)、事件、規格中全部 35 種 action(速度控制、變換車道、瞬間移動、沿軌跡行駛、啟用控制器等),以及全部 19 種 trigger 條件(另加 6 種進階條件),可用 AND / OR 邏輯組合。
END 與 FAIL 條件,在場景執行時產出 PASS / FAIL 判定。
在瀏覽器中執行,底層是編譯為 WebAssembly 的 esmini——具備播放控制、逐格精確的時間軸拖曳、跟隨鏡頭、幽靈軌跡,以及可選的執行過程 3D 預覽——讓你不必離開頁面就能檢視場景執行結果。同一個 .xosc 也能原封不動地在原生 esmini 安裝環境中執行。
匯出為 OpenSCENARIO 1.0、1.1 或 1.2(1.3 尚未支援),並可一併匯出 OpenDRIVE 的 <junction> / <connection> 元素與以 <signal> 表示的交通標誌。

drawtonomy 尚未表達的內容

以下是目前仍需仰賴手寫或程式碼生成 XML 的真實落差：

OpenSCENARIO 1.3 匯出——這個格式支援匯入,但尚未提供為匯出選項。
從零開始建構道路網路時的生產等級 OpenDRIVE <junction> 幾何。路口連接關係在「原封不動延續匯入、未經編輯的 .xodr」時能準確地雙向轉換;從手繪車道合成的新路口幾何目前精度仍不足,且不會建模解析式迴旋曲線幾何。
參數掃描、自訂或 ML 驅動的控制器,以及密集交通流模型。
OpenSCENARIO 2.0 / M-SDL(drawtonomy 目前鎖定 1.x)。

以上情況,手寫或程式碼生成 XML 仍是正確路徑。

合理的混合做法

對於完全在 drawtonomy 中編寫並執行的多數場景,瀏覽器就是事實來源。只在邊界情況才動用手寫 XML：

在 drawtonomy 中編寫場景與故事板——車道網路、參與者、action、trigger、end / fail 條件——並執行以確認判定結果。
如果需要 drawtonomy 尚未輸出的規格功能(某個路口元素、參數掃描、自訂控制器),匯出 .xosc 後手動編輯或以程式碼生成那一部分。
當你需要在大型 catalog 中保留穩定的位元組級 git diff 時,把標準版 XML 留在程式碼中管理,並用 drawtonomy 編寫、檢視、重播個別具體場景。

drawtonomy 是你編寫並執行場景的地方;手寫 XML 則是它尚未觸及的規格角落的退路。

同屬一個 OpenSCENARIO 社群

手寫 XML 是 OpenSCENARIO 的基礎編寫路徑——生態系中的每個其他工具最終都會產生它(或其 DSL 等價物)。drawtonomy 的匯出器、scenariogeneration、Scenic、RoadRunner、Blender DSC 及其他工具,在某個環節都會產生 XML。直接讀寫 XML 是標準保持為標準的方式,而產生 XML 的工具都受益於社群圍繞它建立的跨工具互通性。