OpenScenario Support

[GittUser2021]

Hi, is Sumo Simulator compatible with OpenSCENARIO? I would like to know whether OpenScenerio files can be imported into SUMO and be utilized by SUMO. The use case is that we have many test cases established in OpenScenerio. It might be beneficial to import OpenScenerio into SUMO and run those test cases in SUMO. Thanks.

[namdre]

There is no support for OpenScenario at the moment (only OpenDRIVE). It's likely that support will be added in small steps rather than supporting the whole standard at once. What would be a minimum viable use case? Could you provide a sample OpenScenario file for this?

[Domsall]

I will just take this ticket as reference for the OpenScenario Support.

Like referred to at the conference, OpenScenario consists of 2 parts for us:

• catalogs, which define different objects like vehicles and pedestrians (similar to the vtype-attribute)
• a storyfile with all actions, which includes the scenario and references to all files/objects which need to be loaded

From my perspective, it makes most sense to directly implement OpenScenario 2.0 (although we work with 1.X). Many OpenScenario 1.X readers and generators already exist, some examples:

• scenariogeneration (xosc module), a Python-library with functions to create an OpenScenario file (https://github.com/pyoscx/scenariogeneration)
• QGIS OpenSCENARIO Generation Plugin, QGIS (Python) GUI, to create OpenScenario files (https://github.com/carla-simulator/traffic-generation-editor)
• esmini (ScenarioEngine with the OpenDrive library RoadManager), an OpenScenario Player with GUI (https://github.com/esmini/esmini)
• OpenScenarioEditor (based on esmini-libs), Python-GUI to create an OpenScenario file (https://github.com/ebadi/OpenScenarioEditor)
• Blender Driving Scenario Creator, Python-based Blender Add-On (based on scenariogeneration), to create OpenDrive and OpenScenario files (https://github.com/johschmitz/blender-driving-scenario-creator)
• OpenScenario API, C++-API/library to read OpenScenario files (https://github.com/RA-Consulting-GmbH/openscenario.api.test)
• ScenarioRunner for CARLA, Python Interface to read OpenScenario files and let them replay in Carla (https://github.com/carla-simulator/scenario_runner)
• ad-xolib, a C++ library to read/parse an OpenScenario file (https://github.com/javedulu/ad-xolib)
• openPASS can create and read OpenScenario files (https://gitlab.eclipse.org/eclipse/simopenpass/simopenpass)

The questions I have are:

1. Does it make more sense to add the functions directly to the C++-Code or to add python-files, which convert the OpenScenario-files to a SUMO-readable format before simulating?! The storyfile could be converted into a traci run-file.
2. Some information is irrelevant to SUMO, so what to do with that information (see https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.1.1_Model_Documentation/modelDocumentation/index.html)? For example, I added miscelleneous objects as poi-definition.
3. Which library can/should be used?
4. What happened to the YASE framework? Can this be "easily" integrated? Repo: https://gitlab.eclipse.org/eclipse/simopenpass/yase, Video from the 2021 SUMO User Conference: https://www.youtube.com/watch?v=V0vGpiNdSrc

@namdre maybe you have some other questions/unanswered points we can clarify before digging deeper. This could also be a topic for the openmobility group.

[namdre]

1. so far all our demand-generating tools work by pre-processing some inputs to generate route-files (etc.). While a few were implemented in C++ (od2trips, dfrouter,...), by now the majority of demand tools are implemented in python. I think the openScenario importer could be a python tool (or tools) as well unless there is a good reason against it (i.e. a suitable C++ library that is license-compatible and can be integrated).

2. Ignoring those parts or generating shapes/pois for information purpose would be my suggestion

3. Thanks for providing the list of reference. I prefer something lightweight but haven't had the time to evaluate the list in depth and sort them by this metric. I'm open for suggestions.

4. as far as I can tell, YASE does not provide front end code for parsing/processing OpenSCENARIO files so it's not terribly relevant to our purpose

[namdre]

The story file data might also be tackled via #1922 at least for static trajectories.

[rupeshnanjara]

@namdre Hello, I've been working on Sumo and wanted to see if the sumo cfg or net files can be converted or exported into Openscenario format or not? Any suggestions would help.

@GittUser2021 Did you get a chance to work on this further? Thank you!

[namdre]

@rupeshnanjara No work has been done on this yet on the SUMO side (except for continuous work on OpenDRIVE support).

[prasuka4]

Hello, Is there any update about this work. As I'm very much interested to work with openscenrio for the projects using SUMO. Please do let me know Thanks

[Domsall]

Hi @prasuka4, the work I have done so far involves code I cannot share. Maybe I can get a student working on python Code. We can then share that with the community.

The basic structure: An OpenSCENARIO "story" has 2 parts. The story file and catalogs with information of the relevant objects. For it to work in SUMO, we parse the catalogs in beforehand and translate/transform the information into "additional"-files. The story file is translated/transformed into a traci-file, which can simply be a series of traci-commands.

[daqiu12]

I want to ask, is there any way to view the Python code that supports OpenSCENARIO 2.0 mentioned above now?

[Domsall]

Unfortunately nothing was done from our side yet regarding the Python code. Maybe I can ask ChatGPT to translate my Matlab code to Python. But this will still take a while, as I am working on different projects right now.

[daqiu12]

Thank you for your response! Is there a plan for SUMO to support OpenScenario 2.0? You mentioned earlier that the Matlab code cannot be shared, so do I have to wait for your Python code?

[Domsall]

You can absolutely write code yourself. All information I can provide is above. I currently do not see any benefit using 2.X over 1.X. But that may only be my opinion, as I am familiar with 1.X and not 2.X.

[daqiu12]

Thanks for your answer！