OpenSimulationInterface
Tunnel description in OSI
In the latest version, the lane is hardly to be described as a part of a tunnel, even through lane boundary TYPE_STRUCTURE, e.g. tunnel height, tunnel shape and so forth. Would it be something to think about here? Since sensors are sensitive to tunnels in any case... @CarloVanDriestenBMW
Hi @haoyuanying , could you elaborate on the concrete requirements you have towards tunnel descriptions? I guess you need more details for the sensor model effects for radars in tunnels? I actually had the same thought just some days ago! :)
Requirement to model tunnels came up again in #537 .
As also ghost wrote, it would be good to have a more specific description about the requirement. For sure a geometric description is needed. Open: In OpenDrive the tunnel is a simple attribute of the road. In OSI unclear: Three Objects (2x Wall, 1x Overhead Structure)?
Plan is to discuss it in the next Harmonization Group meeting.
This topic was in discussion in Harmonisation group at 03.08.2021:
For harmonization with OpenDRIVE, there is only very simple description of tunnels. Before integrating new information to the model, further reconcilation needs to be done:
- @kmeids We need to know, what information from sensor model developers are needed.
- It could be necessary to synchronize with #544 . The environment information can at the moment only be set globally. A tunnel could need local environment information, e.g. dimmed light or "no rain".
From the sensor model point of view a few tunnel attributes would support dealing w/ the challenge of how to model radar/lidar behaviour inside a tunnel (just to get a rough idea, what might happen there, take a look into into dataset #110 from the radar scenes collection https://radar-scenes.com). E.g.
- shape (walls, ceiling)
- any particular infrastructure inside the tunnel like emergency exits, fans, ... (basically items come up w/ edges)
@thempen, @raue, From a "Physics-Based" sensor model perspective, we would only need the 3D geometry and associated material properties. (I can't comment on Object-Based or Phenomenological sensor models though)
Requirements would need to come from sensor modellers, therefore deleting RoadModel label.
