Przejdź do głównej zawartości
drawtonomy drawtonomy

drawtonomy vs ręcznie pisany XML OpenSCENARIO

Ręcznie pisany XML OpenSCENARIO

Dział zatytułowany „Ręcznie pisany XML OpenSCENARIO”

Ręczne pisanie XML OpenSCENARIO to popularny przepływ pracy i dla wielu zastosowań właściwy.

Kiedy XML jest odpowiednią ścieżką:

  • Scenariusz jest mały i zależy Ci na kontroli na poziomie pojedynczych bajtów.
  • Generujesz XML programowo z DSL lub potoku generowania kodu.
  • Potrzebujesz funkcji specyfikacji, których drawtonomy nie emituje — przeglądów parametrów (parameter sweep), niestandardowych lub sterowanych ML kontrolerów, gęstych modeli przepływu ruchu, OpenSCENARIO 1.3.
  • Budujesz nową sieć drogową ze skrzyżowaniami od zera i potrzebujesz produkcyjnej geometrii <junction> — eksport skrzyżowań w drawtonomy jest dokładny, gdy przenosi zaimportowany, nieedytowany plik .xodr, ale generowanie nowej geometrii skrzyżowań z ręcznie narysowanych pasów wciąż ma niską precyzję.
  • Współpracujesz nad dużym katalogiem scenariuszy przez git i liczą się stabilne, bajtowe różnice w XML.

Dla tych przypadków ręcznie pisany lub generowany z kodu XML jest podejściem kanonicznym. Do tworzenia i uruchamiania pojedynczego, konkretnego scenariusza — akcji, warunków wyzwalających i werdyktu PASS / FAIL — edytor wizualny jest zwykle szybszy.

Co drawtonomy potrafi dziś wyrazić

Dział zatytułowany „Co drawtonomy potrafi dziś wyrazić”

Edytor wizualny dla OpenSCENARIO 1.2, który tworzy pełny storyboard na płótnie i uruchamia go w przeglądarce — bez wpisywania XML:

  • 2D odgórną sieć drogową — pasy ruchu, skrzyżowania, linestringi — eksportowaną jako OpenDRIVE 1.8 .xodr, wraz z rozmieszczeniem pojazdów, pieszych, sygnalizacji świetlnej i oznakowania poziomego jako obiektów.
  • Kompletny storyboard: fazy (akty), zdarzenia, wszystkie 35 akcji ze specyfikacji (prędkość, zmiana pasa, teleportacja, podążanie za trajektorią, aktywacja kontrolera i inne) oraz wszystkie 19 warunków wyzwalających (plus 6 zaawansowanych), łączone logiką AND / OR.
  • Warunki END i FAIL, które podczas uruchomienia scenariusza dają werdykt PASS / FAIL.
  • Wykonanie w przeglądarce na esmini skompilowanym do WebAssembly — sterowanie odtwarzaniem, precyzyjne przewijanie klatka po klatce, kamera śledząca, ślady duchów (ghost trails) oraz opcjonalny podgląd 3D przebiegu — dzięki czemu przeglądasz działający scenariusz bez opuszczania strony. Ten sam .xosc uruchomisz też bez zmian w natywnej instalacji esmini.
  • Eksport do OpenSCENARIO 1.0, 1.1 lub 1.2 (1.3 nie jest jeszcze dostępne), a także prymitywy OpenDRIVE <junction>/<connection> i znaki drogowe jako wpisy <signal>.

Czego drawtonomy nie wyraża

Dział zatytułowany „Czego drawtonomy nie wyraża”

Rzeczywiste luki, które nadal wymagają ręcznie pisanego lub generowanego XML:

  • Eksport do OpenSCENARIO 1.3 — format jest obsługiwany przy imporcie, ale nie jest jeszcze oferowany jako cel eksportu.
  • Produkcyjna geometria OpenDRIVE <junction> przy budowaniu sieci drogowej od zera. Łączność skrzyżowań jest odtwarzana dokładnie, gdy przenosi zaimportowany, nieedytowany plik .xodr; generowanie nowej geometrii skrzyżowań z ręcznie narysowanych pasów wciąż ma niską precyzję, a analityczna geometria klotoidalna nie jest modelowana.
  • Przeglądy parametrów, niestandardowe lub sterowane ML kontrolery oraz gęste modele przepływu ruchu.
  • OpenSCENARIO 2.0 / M-SDL (drawtonomy celuje w wersję 1.x).

Dla tych przypadków ręczne pisanie lub generowanie XML pozostaje właściwą drogą.

Rozsądna hybryda

Dział zatytułowany „Rozsądna hybryda”

Dla większości scenariuszy tworzonych i uruchamianych w całości w drawtonomy przeglądarka jest źródłem prawdy. Po ręcznie pisany XML sięgaj tylko na obrzeżach:

  1. Utwórz scenę i storyboard w drawtonomy — sieć pasów, uczestników, akcje, warunki wyzwalające, warunki end / fail — i uruchom go, żeby potwierdzić werdykt.
  2. Jeśli potrzebujesz funkcji specyfikacji, której drawtonomy nie emituje (prymitywu skrzyżowania, przeglądu parametrów, niestandardowego kontrolera), wyeksportuj .xosc i ręcznie zedytuj lub wygeneruj tę jedną część.
  3. Gdy zależy Ci na bajtowych różnicach w git w dużym katalogu, trzymaj kanoniczny XML w kodzie, a drawtonomy używaj do tworzenia, przeglądu i odtwarzania pojedynczych, konkretnych scenariuszy.

drawtonomy to miejsce, w którym tworzysz i uruchamiasz scenariusz; ręcznie pisany XML pozostaje furtką awaryjną dla zakątków specyfikacji, do których jeszcze nie dociera.

W tej samej społeczności OpenSCENARIO

Dział zatytułowany „W tej samej społeczności OpenSCENARIO”

Ręcznie pisany XML jest fundamentalną ścieżką tworzenia dla OpenSCENARIO — każde inne narzędzie w ekosystemie w końcu go produkuje (albo jego odpowiednik w DSL). Eksporter drawtonomy, scenariogeneration, Scenic, RoadRunner, Blender DSC i pozostałe narzędzia — wszystkie w pewnym momencie emitują ten XML. Czytanie i pisanie XML bezpośrednio to sposób, w jaki standard pozostaje standardem, a narzędzia, które go produkują, korzystają z międzynarzędziowej interoperacyjności zbudowanej przez społeczność.

Powiązane artykuły

Dział zatytułowany „Powiązane artykuły”