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

Czym jest OpenSCENARIO?

OpenSCENARIO to otwarty standard ASAM do opisu dynamicznych scenariuszy jazdy — tego, co pojazd ego i pozostali uczestnicy ruchu robią w czasie, w formie, którą symulatory mogą odtworzyć. To de facto format wymiany dla testowania opartego na scenariuszach w systemach jazdy autonomicznej.

Dwie rodziny OpenSCENARIO

Dział zatytułowany „Dwie rodziny OpenSCENARIO”

Pod tą samą nazwą kryją się dwa w dużej mierze niezależne standardy:

  • OpenSCENARIO 1.x — oparty na XML. Stabilny, szeroko wspierany. Wersja 1.3 to aktualny cel produkcyjny dla większości narzędzi.
  • OpenSCENARIO 2.0 / DSL — język dziedzinowy do scenariuszy abstrakcyjnych, parametrycznych i probabilistycznych. Nowszy, bardziej ekspresywny, ze stale rosnącym wsparciem narzędziowym.

Formaty te nie są wymienne, ale to właśnie 1.x napędza dziś większość symulatorów i potoków testowych SOTIF / ISO 21448.

Co zawiera plik OpenSCENARIO 1.x

Dział zatytułowany „Co zawiera plik OpenSCENARIO 1.x”

Typowy scenariusz 1.x składa się z:

  • Odniesienia RoadNetwork — zwykle plik OpenDRIVE .xodr, opcjonalnie sparowany z plikiem sceny takim jak .osgb.
  • Bloku Entities — pojazdów, pieszych i innych obiektów.
  • Storyboard — uporządkowanych chronologicznie aktów, manewrów i zdarzeń wykonywanych przez uczestników.
  • Akcji Init — pozycji startowych, prędkości i przypisań parametrów.

Dla pojedynczego krótkiego scenariusza XML czyta się naturalnie, ale przy skalowaniu do kilkudziesięciu wariantów staje się trudny w utrzymaniu. Tu z pomocą przychodzą narzędzia do tworzenia scenariuszy oraz DSL-e.

Typowe podejścia do tworzenia scenariuszy

Dział zatytułowany „Typowe podejścia do tworzenia scenariuszy”
  • Ręcznie pisany XML. Popularny w małych zespołach i przy referencyjnych (ground-truth) przypadkach testowych.
  • DSL / generowanie kodu. OpenSCENARIO 2.0 DSL, Scenic lub własne generatory, które emitują XML na podstawie opisu wyższego poziomu.
  • Biblioteki Python. scenariogeneration (dawniej pyoscx / pyodrx) udostępnia programowe API dla OpenSCENARIO + OpenDRIVE, obejmujące wersje od V1.0 do V1.3.1.
  • Silniki scenariuszy wbudowane w symulatory. CARLA ScenarioRunner definiuje i wykonuje scenariusze dla CARLA, z obsługą Pythona oraz OpenSCENARIO 1.0 / 2.0.
  • Edytory wizualne. MathWorks RoadRunner (eksport do XML i DSL), Truevision Designer (skupiony na OpenDRIVE), Blender Driving Scenario Creator (wtyczka do Blendera) oraz drawtonomy (tworzy pełne storyboardy OpenSCENARIO 1.x i uruchamia je w przeglądarce na esmini-WASM).

Produkcyjne tworzenie scenariuszy zwykle łączy kilka z tych podejść naraz — często bibliotekę Python lub DSL dla samych scenariuszy, a edytor wizualny dla sieci drogowej.

Miejsce drawtonomy w ekosystemie

Dział zatytułowany „Miejsce drawtonomy w ekosystemie”

drawtonomy to środowisko do tworzenia i uruchamiania scenariuszy OpenSCENARIO 1.x w przeglądarce — tablica, na której narysowana scena staje się gotowym do odtworzenia storyboardem. Narzędzie importuje OpenSCENARIO 1.x i eksportuje OpenSCENARIO 1.0–1.2 (wersja 1.3 wkrótce), a także OpenDRIVE 1.8:

  • Umieszczaj pasy ruchu, skrzyżowania, pojazdy, pieszych, sygnalizację świetlną i oznakowanie poziome na płaskim płótnie z widokiem z góry.
  • Buduj storyboard wizualnie — fazy, zdarzenia, 35 akcji i 19 warunków wyzwalających — i uruchamiaj go w przeglądarce na esmini skompilowanym do WebAssembly, z podglądem 3D (kamery Chase / z lotu ptaka / kierowcy) obok płótna 2D.
  • Importuj istniejącą parę .xosc + .xodr i edytuj ją, albo eksportuj parę do natywnego uruchomienia w esmini.
  • Generuj scenariusz z opisu w języku naturalnym: drawtonomy tworzy szkic storyboardu, sprawdza go przez cztery bramki walidacyjne (w tym rzeczywiste uruchomienie w esmini) i nakłada go na płótno.

Eksporter emituje już struktury OpenDRIVE <junction> / <connection> / <laneLink> oraz wpisy <signal> — to nie jest już pozycja na mapie drogowej, tylko działająca funkcja. Ważny jest jednak podział pod względem dokładności: drogi przeniesione bez edycji z zaimportowanego pliku .xodr zachowują swoją oryginalną topologię skrzyżowań z wysoką wiernością, natomiast skrzyżowania zsyntetyzowane od zera z narysowanych ręcznie pasów nie są jeszcze w pełni wiarygodne. Nadal brakuje przeglądów parametrów (parameter sweep) oraz niestandardowych lub sterowanych ML kontrolerów.

Duże, sparametryzowane serie scenariuszy najlepiej nadal generować z DSL-a lub biblioteki Python — to pozostaje poza zakresem edytora wizualnego. drawtonomy dodaje za to szybką wizualną ścieżkę od pomysłu (albo polecenia w języku naturalnym) do gotowego, możliwego do przejrzenia scenariusza.

Powiązane artykuły

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