search

OpenSimulationInterface / open-simulation-interface

A generic interface for the environmental perception of automated driving functions in virtual scenarios.
Other
267 stars 125 forks source link

UC3: Sampled Geometry SensorModel #435

Open kmeids opened 3 years ago

kmeids commented 3 years ago

Describe the feature

Referring to UC3: Sampled Geometry SensorModel, Link

The general aim make use of the Simulation Environment where the solver and associated prerequisites lie, please see the following picture: image

Satisfying the above mentioned use case requires revisiting the SensorView and SensorViewConfigration OSI messages.

For SensorView: Most probably we need to target specific Sensor-Technology SensorView messages, like CameraSensorView

Question-1 Is there a relation between specific Sensor-Technology SensorView messages? For example CameraSensorView have:

  1. image_data
  2. CameraSensorViewConfiguration

image

Is/should the format of the _imagedata be defined in the CameraSensorViewConfiguration message?

Same question for Lidar and Radar.

Question-2 UltrasonicSensorView only contains the UltrasonicSensorViewConfiguration message, any request for obtaining "Raw" data as well?

image

Question-3 How should the SensorData message be adapted/extended first, to make usage of SensorView message extension and second, to support Physics Based Sensor models.

Since SensorViewConfigration message is meant to configure the simulation environment and not the Sensor Model, I am also linking the following issues here: https://github.com/OpenSimulationInterface/open-simulation-interface/issues/432 https://github.com/OpenSimulationInterface/open-simulation-interface/issues/414

Tagging @ThomasSchloemicherAVL as it could be useful for WP13.

Note: This issue aims to introduce these topics on a more abstract level, aiming to start the discussion with other OSI users that are not in ASAM organization. I will open several separate/more specific issues on specific SensorView and SensorViewConfiguration messages as well as for SensorData.

pmai commented 3 years ago

To try to answer your questions from my point of view:

Question-1

The SensorViewConfiguration with its technology-specific submessages provides the configuration of the sensor view that a model receives:

  1. It is used in the autoconfiguration mechanism that OSMPSensorViewInConfigRequest and OSMPSensorViewInConfig parameters provided by the sensor model enable. This mechanism is optional, i.e. there can also be other, manual, ways of setting up the environment simulation to provide the SensorView that a particular model needs.
  2. The actual SensorViewConfiguration that is used to provide a SensorView to a model is contained as a copy inside the SensorView message (and the same is true for the technology-specific sub-messages).

Therefore in your example the image raw data is fully described by the CameraSensorViewConfiguration provided alongside it.

Question-2

Yes, the UltrasonicSensorView and its configuration are currently mostly a stub (though they can give you the mounting position of the transducer), intended for enhancement when needed.

Question-3

There should not be any need to enhance SensorData for physics-based sensor models: The output interface of a sensor model is based on the output interface of the actual sensor, not on the technology used to simulate it.

Hope this helps clarify things a bit...

kmeids commented 3 years ago

@pmai, Thanks for your feedback!

For questions 1 and 2 we should only have a follow-up on the "Documentation". I'll make sure to pass this to our service providers.

On question 3, we would eventually need to update the following representation: image

This is something that we are tryin to achieve in the "Architecture-Group".