Closed jruebsam closed 4 months ago
@pmai @ThomasNaderBMW @PhRosenberger any suggestions how to proceed with this or if this should be discussed in a Subgroup?
@jruebsam if I understand you correctly, you would like to know what the simulated sensor could have seen (a.k.a. nominal FoV) in comparison to the actual output data? I wonder why it is restricted to a ground projection and not 3D or even 4D (incl. velocity or intensity). However, do you know our concept of a "Unified relevance region from sensor model knowledge" from this paper: https://tuprints.ulb.tu-darmstadt.de/18950/ ? - This seems related to your thoughts, right?
Are you attending the GSVF next week? - Would be great to discuss it there in person:-)
@PhRosenberger THanks for the reply, yes it would be something like a nominal FOV. In our usecase we want to use this in a visualizer thats why its only 2D, since 3D FOVs can become quiet confusing. Unfornutanely I will not be able to join GSVF, but also thanks for the paper.
@jruebsam Oh, what a pity that we cannot meet this week!
However, for your use case, I see the existing GenericSensorView as an option: https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/gen/structosi3_1_1GenericSensorView.html
What do you think?
@PhRosenberger I thought about that, however GenericSensorView only contains a FOV and a Mounting Position but not a Range. It could be an option that we do some kind of extension at this location.
Yes, this could be a good way to solve this issue. Would you mind atrting a PR for this with the extension on GenericSensorViewConfiguration?
@PhRosenberger I'm not against adding a range field to GenericSensorViewConfiguration in general as I feel like it would be a consistent addition to the FoV fields. I don't know the reasons why it wasn't initially added though. But I think, if it was there, it then should only be used for the configuration of the input which is quite different from an intended sensor model output range. E.g. requiring/providing only a specific excerpt of ground truth information to a sensor model is different from describing its intended output range.
Adding something like a VirtualDetectionArea to SensorData would IMO correctly indicate that it actually refers to the sensor model output.
But I also agree that we should at least offer 3D boundary points.
Ok I think then we have two different cases:
So we need to different PRs to solve this issue here, right?
Adressed by #781
Virtual Detection Area
Currently it is not possible from a SensorData message to get an understanding what the current area of observation of a sensor model is.
I would like to have some kind of message, lets say a Virtual Detection Area which describes in which kind of FOV the current sensor models operates. This could be a simble generic message which contains a repeated list of points, e.g.
Solution
Since this message is related to the output of a sensor model I would like to add this to the SensorData message. Also this would be important for our current usecase, which is focused on visualization of SensorData messages.