Vtd (virtual Test Drive)

“VIRES Virtual Test Drive” (VTD) is a tool chain and modular framework for the provision of virtual environments in engineering simulations for the automotive and railroad industry. Virtual Test Drive (VTD) provides a combination of the central task and data control, traffic and scenario simulation, image generator and sensor simulation. This is one of the most comprehensive tool for the purpose of development, testing and verification for driver assistance systems, autonomous driving systems and active safety systems. VTD has inbuilt tools for road generation, traffic simulation, scenario generation, sound simulation, image generation and simulation control. It uses established standard file formats for the above purpose. Figure : VTD System Overview Vires Structure: The overall configuration and data organization is distributed over three different levels: 1) Distributions (Data/Distros) 2) Setups (Data/Setups) 3) Projects (Data/Projects) Configuration and simulation data for run-time components may be found in all three levels. A so-called file finder is used to locate data searching for it from the specific (project) level to the general level (distribution). 2.3.2 Distributions A distribution contains the basic configuration and simulation data (e.g. visual databases) which is applicable to all kinds of setups and projects (see below). The data is organized by VIRES upon packing of the release. No user-data shall be placed within the Distros directory. The applicable distribution is symbolically linked to Current in the directory Data/Distros. This link may be changed by invoking the script selectDistro.sh in the same directory. 2.3.3 Setups “Setups” represent different environments in which VTD is supposed to run. With the introduction of the setups, a stronger concept of separation of platforms from project data has been realized. The following setups are part of the default distribution: Standard desktop installation, single machine Joystick for joystick / game-wheel operation MultiChannel3 3-channel IG on various machines Stereo stereo setup of IG 2.3.4 Projects: Project data defines the actual content of a simulation. The project contains the different scenarios that are created for testing, Image Generator and many other actual simulation data are located in the projects. VTD Components: The sole purpose of VTD unites control, operation, and simulation. The task and data control has an open loop operation. It’s simulation and frame control does the external and internal triggering on both real-time and non-real-time mode. It performs single step mode operation. The frame can be synchronous vs. free mode, as we can see in figure 1.3. Simulation and configuration control are dedicated for scenario management and control of simulation stages. It can also run on master and slave mode. This also links multiple operations in team-operation mode.

Traffic and scenario simulation assigns realistic density and features in urban, rural and motorway environment, which include vehicles and pedestrians for more than 100+ entities. It also has traffic light including a controller. The realistic autonomous behavior and fully controlled behavior can make the simulation options much easier and handy to the user. It can integrate seamlessly to multiple externally controlled entities and also can link to traffic flow simulation. The exact road description is given by OpenDRIVE [3] or OpenCRG [4] to complete ground-truth data. The sensor simulator input data contains image, object list or ray tracing information. The perfect sensor includes working on object list, object filtering, calculation of obstruction, extraction of road marks and extraction of traffic signs. The crash sensor contacts with other players, obstacles and static elements. Ray-tracing radar prototypes have detailed material properties, multiple reflections, absorption, attenuation, scattering, etc. Custom sensors consist of plug-in of module manager and uses SDK4. This is also a plug-in of VIRES Image Generator. The entire module has capacity for custom sensors. Figure : VTD Components in Detail A Breif overview of various VTD components can be understood from the above figure. A more detailed explanation on defining the sensors in modulemanager.xml file will be give in the next section. Module Manager: The module manager provides a means to run (custom) plug-ins within the VTD environment. Two sorts of plugins are available: - sensor plugins - dynamics plugins Figure: Module Manager Dynamics Plugins: Dynamics plugins are used for the simulation of a vehicle’s dynamic bahavior according to driver inputs (brake, throttle, steering). Sensor Plugins: Sensor plugins are used for the processing (e.g. filtering) of the simulated environment. The results may be used as inputs for the interpretation in algorithms of active safety and assistance systems. One key feature of the sensor models is the filtering of all available data into a reduced stream of relevant data within certain spatial constraints (see following figure) which can be forwarded to other components. Two types of Sensor plugins are used for this simulation.

1). Multiray Sensor (Simulates the ultrasonic sensor behavior)

2). GPS Sensor (To obatain the odometry information) Multiray Sensor: GPS Sensor: Communication Interfaces The components communicate via two categories of interfaces: private and public ones. The private interfaces are used for optimized internal communication of some VTD components provided by VIRES.

The public interfaces are used for the broad majority of communication with either components provided by VIRES or with 3rd party components. The public interfaces are: Runtime Data Bus (RDB): RDB is a unified network interface for all information available within VTD which may be of interest for external components. Its binary communication protocol is TCP and UDP. Using RDB, run-time data may be exchanged directly between the VTD core components and e.g. 3rd party tools.

Two classes of RDB data streams are available: general run-time data and image data. Both streams run via dedicated network ports. So-called sensor plug-ins of the Module Manager may be used to extract data in an area of interest (sensor range) from the full RDB data stream; they will output their data also using the RDB protocol so that a user may connect his components either to the original RDB data stream (from TC) or to a sensor output (RDB(2) in the figure above).

Simulation Control Protocol (SCP): SCP is a unified bi-directional network interface for configuration and command sequences. The low level protocol of this interface is based on a data stream which combines a binary header followed by ASCII data. The ASCII data is formatted as a human-readable stream with XML syntax. Multiple components may connect to the SCP data port. All commands sent from one participant into the system will be reflected to all other participants. Via SCP the user may control parts or all of the simulation. The VtGui which usually provides the user interface for simulation control also uses SCP as means to connect to the simulation.

VTD Applications: The major applications of VTD are: Assessment of advanced driver assistance system(ADAS), Autonomous Driving and active safety systems in software/driver/vehicle/hardware-in-the-loop environments.