Pular para o conteúdo

drawtonomy vs OpenSCENARIO XML escrito à mão

Escrever XML do OpenSCENARIO à mão é um fluxo de trabalho comum e, para muitos casos, é o caminho certo.

Quando o XML é o caminho adequado:

  • O cenário é pequeno e você quer controle no nível de bytes.
  • Você está gerando o XML programaticamente a partir de um DSL ou pipeline de codegen.
  • Você precisa de recursos da especificação que o drawtonomy ainda não emite — varreduras de parâmetros, controladores personalizados ou baseados em ML, modelos de tráfego denso, OpenSCENARIO 1.3.
  • Você está construindo uma malha viária nova com cruzamentos do zero e precisa de geometria <junction> em nível de produção — a exportação de cruzamentos do drawtonomy é fiel quando carrega um .xodr importado e não editado, mas gerar geometria de cruzamento nova a partir de faixas desenhadas à mão ainda tem baixa precisão.
  • Você está colaborando em um catálogo grande via git e diffs estáveis de XML byte a byte importam.

Nesses casos, XML escrito à mão ou gerado por código é a abordagem canônica. Já para criar e rodar um cenário concreto único — ações, triggers e um veredito PASS / FAIL — um editor visual costuma ser mais rápido.

Um editor visual para OpenSCENARIO 1.2 que monta o storyboard inteiro no canvas e o executa no navegador — sem digitar uma linha de XML:

  • Uma malha viária 2D vista de cima — faixas, cruzamentos, linestrings — exportada como .xodr OpenDRIVE 1.8, além do posicionamento de veículos, pedestres, semáforos e marcações viárias como entidades.
  • Um storyboard completo: fases (acts), eventos, todas as 35 ações da especificação (velocidade, mudança de faixa, teletransporte, seguir trajetória, ativar controlador, entre outras), e todas as 19 condições de trigger (mais 6 avançadas) combinadas com lógica AND / OR.
  • Condições END e FAIL que geram um veredito PASS / FAIL ao rodar o cenário.
  • Execução no navegador sobre o esmini compilado para WebAssembly — controles de reprodução, seek com precisão de frame, câmera de acompanhamento, rastros fantasma e uma prévia 3D opcional da execução — tudo sem sair da página. O .xosc também roda sem alterações em uma instalação nativa do esmini.
  • Exportação para OpenSCENARIO 1.0, 1.1 ou 1.2 (1.3 ainda não disponível), além das primitivas <junction>/<connection> do OpenDRIVE e sinais de trânsito como entradas <signal>.

As lacunas reais que ainda exigem XML escrito à mão ou gerado:

  • Exportação para OpenSCENARIO 1.3 — o formato é suportado na importação, mas ainda não está disponível como destino de exportação.
  • Geometria <junction> do OpenDRIVE em nível de produção ao construir uma malha viária do zero. A conectividade dos cruzamentos é fiel quando carrega um .xodr importado e não editado; gerar geometria de cruzamento nova a partir de faixas desenhadas à mão ainda tem baixa precisão, e geometria analítica de clotoide não é modelada.
  • Varreduras de parâmetros, controladores personalizados ou baseados em ML, e modelos de tráfego denso.
  • OpenSCENARIO 2.0 / M-SDL (o drawtonomy tem como alvo a série 1.x).

Para esses casos, escrever ou gerar XML continua sendo o caminho certo.

Para a maioria dos cenários, você cria e roda tudo dentro do drawtonomy — o navegador é a fonte da verdade. Recorra a XML escrito à mão só nas bordas:

  1. Monte a cena e o storyboard no drawtonomy — malha de faixas, participantes, ações, triggers, condições de fim / falha — e execute para confirmar o veredito.
  2. Se precisar de um recurso da especificação que o drawtonomy não emite (uma primitiva de cruzamento, uma varredura de parâmetros, um controlador personalizado), exporte o .xosc e edite ou gere manualmente essa parte.
  3. Quando quiser diffs de git byte a byte em um catálogo grande, mantenha o XML canônico em código e use o drawtonomy para criar, revisar e reproduzir cenários concretos individuais.

O drawtonomy é onde você cria e roda o cenário; o XML escrito à mão continua sendo a válvula de escape para os cantos da especificação que ele ainda não alcança.

XML escrito à mão é o caminho fundamental de autoria do OpenSCENARIO — toda outra ferramenta do ecossistema acaba produzindo esse XML (ou seu equivalente em DSL). O exportador do drawtonomy, o scenariogeneration, o Scenic, o RoadRunner, o Blender DSC e os demais emitem o XML em algum ponto. Ler e escrever o XML diretamente é o que mantém o padrão sendo de fato um padrão, e as ferramentas que o produzem se beneficiam da interoperabilidade que a comunidade construiu em torno dele.