drawtonomy vs 직접 작성하는 OpenSCENARIO XML

직접 작성하는 OpenSCENARIO XML

OpenSCENARIO XML을 직접 작성하는 것은 흔한 워크플로이고, 많은 경우 여전히 옳은 선택입니다.

XML이 적합한 경우:

시나리오가 작아서 바이트 단위 제어가 필요할 때.
DSL이나 코드 생성 파이프라인에서 XML을 프로그래밍적으로 뽑아낼 때.
drawtonomy가 아직 출력하지 못하는 스펙 기능이 필요할 때 — 파라미터 스윕, 커스텀 / ML 컨트롤러, 밀도 높은 교통 흐름 모델, OpenSCENARIO 1.3.
처음부터 교차로가 있는 도로망을 새로 구성하면서 프로덕션급 <junction> 기하가 필요할 때. drawtonomy의 junction 내보내기는 가져온 .xodr을 편집하지 않고 그대로 통과시킬 때는 정확하지만, 손으로 그린 레인에서 새 교차로 기하를 합성하는 정밀도는 아직 낮습니다.
git으로 대형 카탈로그를 협업하며 안정적인 바이트 단위 XML diff가 중요할 때.

이런 경우라면 직접 작성하거나 코드로 생성한 XML이 정석입니다. 다만 action·trigger·PASS / FAIL 판정이 있는 단일 구체 시나리오를 저작하고 실행하는 용도라면 시각 편집기가 대체로 더 빠릅니다.

drawtonomy가 지금 표현할 수 있는 것

OpenSCENARIO 1.2의 전체 스토리보드를 캔버스에서 구성하고 브라우저에서 바로 실행하는 시각 편집기입니다 — XML을 직접 타이핑할 필요가 없습니다.

레인, 교차로, 라인스트링으로 이루어진 2D 탑다운 도로망을 OpenDRIVE 1.8 .xodr로 내보내고, 차량·보행자·신호등·노면 표시를 엔티티로 배치합니다.
완전한 스토리보드: phase(act), event, 스펙이 정의하는 action 35종 전체(속도, 차선 변경, 텔레포트, 궤적 추종, 컨트롤러 활성화 등)와 trigger 조건 19종(+ advanced 6종)을 AND / OR 로직으로 조합합니다.
시나리오 실행 시 PASS / FAIL 판정을 내리는 END / FAIL 조건.
WebAssembly로 컴파일된 esmini 위에서의 브라우저 내 실행 — 재생 컨트롤, 프레임 단위 seek, 추적 카메라, 고스트 궤적, 선택적 3D 프리뷰까지 페이지를 떠나지 않고 실행 결과를 검토할 수 있습니다. 내보낸 .xosc는 네이티브 esmini 설치본에서도 그대로 실행됩니다.
OpenSCENARIO 1.0, 1.1, 1.2로 내보내기(1.3은 아직 지원하지 않음)에 더해 OpenDRIVE <junction> / <connection> 프리미티브와 <signal> 항목으로서의 교통 표지 내보내기.

drawtonomy가 표현하지 못하는 것

여전히 직접 작성하거나 생성한 XML이 필요한 실제 한계:

OpenSCENARIO 1.3 내보내기 — import는 지원하지만 export 대상으로는 아직 제공하지 않습니다.
처음부터 도로망을 구성할 때의 프로덕션급 OpenDRIVE <junction> 기하. 가져온 .xodr을 편집하지 않고 통과시킬 때는 교차로 연결성이 정확히 왕복되지만, 손으로 그린 레인에서 새 교차로 기하를 생성하는 정밀도는 아직 낮고, 해석적 클로소이드 기하는 모델링하지 않습니다.
파라미터 스윕, 커스텀 또는 ML 기반 컨트롤러, 밀도 높은 교통 흐름 모델.
OpenSCENARIO 2.0 / M-SDL (drawtonomy는 1.x를 대상으로 합니다).

이런 부분은 여전히 직접 작성하거나 생성한 XML이 옳은 길입니다.

합리적인 하이브리드

대부분의 시나리오는 drawtonomy 안에서 온전히 저작하고 실행할 수 있습니다 — 브라우저가 원본(source of truth)입니다. 직접 작성한 XML은 다음과 같은 경계 지점에서만 꺼내 씁니다.

drawtonomy에서 장면과 스토리보드를 저작합니다 — 레인 네트워크, 참여자, action, trigger, end / fail 조건 — 그리고 실행해서 판정을 확인합니다.
drawtonomy가 아직 출력하지 못하는 스펙 기능(교차로 프리미티브, 파라미터 스윕, 커스텀 컨트롤러 등)이 필요하면 .xosc를 내보내 그 부분만 직접 수정하거나 코드로 생성합니다.
대형 카탈로그 전반에서 바이트 단위 git diff가 필요하다면 정본 XML을 코드로 관리하고, drawtonomy로는 개별 구체 시나리오를 저작·검토·재생합니다.

시나리오를 저작하고 실행하는 곳은 drawtonomy이고, 직접 작성한 XML은 drawtonomy가 아직 닿지 않는 스펙의 구석을 위한 탈출구로 남습니다.

같은 OpenSCENARIO 커뮤니티에서

직접 작성하는 XML은 OpenSCENARIO의 근본적인 저작 경로입니다 — 생태계의 다른 모든 도구가 결국은 이 XML(또는 그에 대응하는 DSL)을 만들어냅니다. drawtonomy의 exporter, scenariogeneration, Scenic, RoadRunner, Blender DSC 등 나머지 도구들도 결국 이 지점에서 XML을 내보냅니다. XML을 직접 읽고 쓰는 것이야말로 이 표준을 진짜 표준으로 유지하는 방법이고, XML을 생성하는 도구들은 커뮤니티가 그 주변에 쌓아 온 도구 간 상호운용성의 혜택을 함께 받습니다.