Salta ai contenuti
drawtonomy drawtonomy

drawtonomy vs OpenSCENARIO XML scritto a mano

OpenSCENARIO XML scritto a mano

Sezione intitolata “OpenSCENARIO XML scritto a mano”

Scrivere a mano XML OpenSCENARIO è un flusso di lavoro comune e per molti casi d’uso quello giusto.

Quando l’XML è il percorso appropriato:

  • Lo scenario è piccolo e vuoi controllo a livello di byte.
  • Stai generando XML programmaticamente da un DSL o una pipeline di codegen.
  • Ti serve una feature della specifica che drawtonomy non emette — sweep di parametri, controller personalizzati o guidati da ML, modelli di flusso di traffico denso, OpenSCENARIO 1.3.
  • Stai costruendo da zero una nuova rete stradale con giunzioni e ti serve geometria <junction> di livello produzione — l’export delle giunzioni di drawtonomy è accurato quando riporta invariato un .xodr importato, ma generare nuova geometria di giunzione da corsie disegnate a mano è ancora poco preciso.
  • Stai collaborando su un grande catalogo via git e contano diff XML stabili a livello di byte.

Per questi casi, l’XML scritto a mano o generato da codegen è l’approccio canonico. Per comporre ed eseguire un singolo scenario concreto — azioni, trigger e un verdetto PASS / FAIL — un editor visuale è di solito più rapido.

Cosa drawtonomy può esprimere oggi

Sezione intitolata “Cosa drawtonomy può esprimere oggi”

Un editor visuale per OpenSCENARIO 1.2 che compone uno storyboard completo sul canvas e lo esegue nel browser — senza scrivere XML:

  • Una rete stradale 2D dall’alto — corsie, incroci, linestring — esportata come OpenDRIVE 1.8 .xodr, più il posizionamento di veicoli, pedoni, semafori e segnaletica come entità.
  • Uno storyboard completo: fasi (atti), eventi, tutte le 35 azioni previste dalla specifica (velocità, cambio corsia, teletrasporto, follow-trajectory, activate-controller e altre), e tutte le 19 condizioni di trigger (più 6 avanzate) combinate con logica AND / OR.
  • Condizioni END e FAIL che producono un verdetto PASS / FAIL quando lo scenario viene eseguito.
  • Esecuzione in-browser su esmini compilato in WebAssembly — controlli di riproduzione, seek con precisione al frame, camera di inseguimento, tracce ghost e un’anteprima 3D opzionale del run — così rivedi lo scenario in esecuzione senza lasciare la pagina. Il .xosc gira invariato anche in un’installazione esmini nativa.
  • Esportazione verso OpenSCENARIO 1.0, 1.1 o 1.2 (la 1.3 non è ancora disponibile), oltre a primitive OpenDRIVE <junction>/<connection> e segnaletica stradale come voci <signal>.

Cosa drawtonomy non esprime

Sezione intitolata “Cosa drawtonomy non esprime”

Le lacune reali che richiedono ancora XML scritto a mano o generato:

  • Esportazione OpenSCENARIO 1.3 — il formato è supportato in importazione ma non ancora offerto come target di esportazione.
  • Geometria OpenDRIVE <junction> di livello produzione quando costruisci una rete stradale da zero. La connettività delle giunzioni fa un round-trip accurato quando riporta invariato un .xodr importato; generare nuova geometria di giunzione da corsie disegnate a mano è ancora poco preciso, e la geometria analitica a clotoide non è modellata.
  • Sweep di parametri, controller personalizzati o guidati da ML, e modelli di flusso di traffico denso.
  • OpenSCENARIO 2.0 / M-SDL (drawtonomy punta a 1.x).

Per questi casi, scrivere o generare l’XML resta il percorso giusto.

Un ibrido ragionevole

Sezione intitolata “Un ibrido ragionevole”

Per la maggior parte degli scenari che componi ed esegui interamente in drawtonomy, il browser è la fonte di verità. Ricorri all’XML scritto a mano solo ai margini:

  1. Componi la scena e lo storyboard in drawtonomy — rete di corsie, partecipanti, azioni, trigger, condizioni end / fail — ed eseguilo per confermare il verdetto.
  2. Se ti serve una feature della specifica che drawtonomy non emette (una primitiva di giunzione di livello produzione, uno sweep di parametri, un controller personalizzato), esporta lo .xosc e modifica a mano o genera da codice quella singola parte.
  3. Quando vuoi diff git a livello di byte su un grande catalogo, tieni l’XML canonico nel codice e usa drawtonomy per comporre, rivedere e riprodurre i singoli scenari concreti.

drawtonomy è dove componi ed esegui lo scenario; l’XML scritto a mano resta la via di fuga per gli angoli della specifica che non copre ancora.

Nella stessa comunità OpenSCENARIO

Sezione intitolata “Nella stessa comunità OpenSCENARIO”

L’XML scritto a mano è il percorso di authoring fondamentale per OpenSCENARIO — ogni altro strumento nell’ecosistema alla fine lo produce (o il suo equivalente DSL). L’esportatore di drawtonomy, scenariogeneration, Scenic, RoadRunner, Blender DSC e il resto producono tutti l’XML a un certo punto. Leggere e scrivere l’XML direttamente è come lo standard rimane uno standard, e gli strumenti che lo producono beneficiano dell’interoperabilità cross-tool che la comunità ha costruito attorno ad esso.

Letture correlate

Sezione intitolata “Letture correlate”