Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
OpenADx/TestbedCandidates
Contents
Testbed Candidates
Candidate 1: Simulation
Challenge
The challenge in the simulation of AD functions is the big amount of test cases which can be easily generated by variation of parameters. This big amount of test cases should be handled with parallel execution of test case in multiple instances of the simulation environment.
Use Case Step 1
Target for step 1 of the testbed is the easy integration of simulation tools and function under test allowing to feed a test scenario into the simulation and to get out data for further analysis and visualization.
Acceptance Criteria:
- The simulation can easily be set up, necessary functionality for integrating and coordinating the different components of the simulation is available.
- Sinks for simulation data out of the single components but also out of the communication between the components can be attached and the data can be logged and processed during the simulation.
- The framework allows to integrate multiple simulation tools and offers a standard communication mechanism. New tools can be integrated by providing a connector between the communication mechanism and the tool.
- The simulation execution setup is prepared for containerization in order to support easy setup and execution in parallel on a scalable hardware platform without extensive installation and maintenance efforts.
Goal for Step 1: Create demonstrators that combine a simple function under test provided by Bosch and the different simulation tools which come with a relevant plant model. For scenarios to demonstrate it is planned to look into Pegasus with the potential addition of a traffic simulated by Eclipse Sumo. The scenario should be based on a closed-loop simulation that uses a model of identified objects as input for the control algorithm.
Base Architecture Step 1
The following picture shows the basic idea for the realization of step 1.
The base decision is to use DDS as the central messaging service between the simulation components. The DDS component has to be chosen in a ROS2 compatible way in order to use the ROS2 mechanisms for data access. DDS/ROS2 compliant components are connected directly to the DDS layer, whereas simulation components not compatible with DDS are attached using a dedicated connector between the component and the DDS-API.
The Simulation Framework is basically a conglomeration of support functionality which builds the glue between the participating components. It offers functionality like the above mentioned connectors, but also time management and other functionality needed to smoothly run the simulation. This component is the main target for the testbeds step 1, since it contains the stuff needed but not provided by existing tools.
On top of these base functionalities, there are simulation tools and the function under test which build the core of the simulation, i.e., the representation of the environment and the control algorithms which observe or even act in this environment. Both provide information on the simulation state in addition to ROS2 means which record the communication between the components.
All recorded data is stored in defined measurement data formats that are stored for further processing. This is represented by the Measurement Data component in the picture which is basically an interface to testbed candidate 2, resp., storing and further processing the recorded data in offline analysis.
For online analysis, tools for visualization or introspection can connect to the DDS communication in the same fashion as the simulation components. This connection allows to control the simulation, e.g., for debugging purposes. The mechanisms rely on the possibilities of ROS2 for interacting with the simulation components.
Tools under investigation concerning usage in the demonstrator currently are:
- DDS - implementation (tbd)
- ROS2/RVIZ
- Matlab/Simulink
- DYNA4
- AirSim
- Gazebo
- Dymola (Modelica) ?
Topics for Step 2
Step 1 creates a simulation environment, that can run "out-of-the-box" with simple configuration. A logical step is to embed this stuff in a management framework that allows to manage scenarios and test cases and on the other hand side supports in gathering the results and evaluate the outcome whether important test criteria have been met or whether test cases have failed while doing that on a large scale in a parallel fashion.
Glossary
Relevant technologies for this testbed are
- Eclipse SUMO (Simulation of Urban Mobility) - http://www.dlr.de/ts/de/desktopdefault.aspx/tabid-9883/16931_read-41
- OpenPASS - https://projects.eclipse.org/proposals/simopenpass
- OpenMDM - https://www.openmdm.org
- OpenDrive - http://www.opendrive.org
- OpenScenario - http://www.openscenario.org
- OpenCRG - http://www.opencrg.org
- Open Simulation Interface - https://github.com/OpenSimulationInterface/open-simulation-interface/wiki
- AirSim - https://www.microsoft.com/en-us/research/project/aerial-informatics-robotics-platform
- Autonomous Driving Cookbook - https://github.com/Microsoft/AutonomousDrivingCookbook
- ROS - http://www.ros.org
- Gazebo - http://wiki.ros.org/gazebo
- Pegasus - http://www.pegasus-projekt.info/en/home
- Proprietary Tools
Candidate 2: Massive data ingest and management
Challenge
Developing and validating AD functions requires the collection of data from various sensors, actuators and other sources. This ideally takes place in a fleet operation. However, due to the required scale and diversity of measurement systems, the AD community faces a massive amount of complex and heterogeneous data.
Descriptions / Goal
This Challenge, i.e. AD data, fulfills all aspects of 'Big Data'. It is of massive volume, there exists a large variety, it is recorded in a high velocity, and usually exists in various formats. However, most available, automotive systems for handling data captured in such an environment cannot process this data in an efficient workflow. Additionally, there exists a painful gap between measurement system and tools, and data analytics and processing platforms.
To solve this challenge, there is the need for a common and open-source handling of measurement data. This should ideally be in the form of common ETL processes, which fill the gap between the heterogeneous measurement data and a suitable backend that already as an industry standard for data analysis.
This solution should incorporate the various formats such as ADTFs .dat, ROS .bag, Vectors .mdf, ...
Suggested work packages
Work package 1 - Problem space
Understand all necessary aspects to clearly define a common problem space. The above the description of the challenge may only cover some parts and is only in the perspective of one stakeholder.
Work package 2 - ETL
Start a sample ETL implementation that provides an efficient ingest of ROS .bag files into a Hadoop environment.
Work package 3 - Data management
Evaluated what is needed to manage this massive, heterogeneous and globally distributed data.