OpenSimulationInterface
Brainstorming for Road Network Model
This issue shall function as a container to catch painpoints of the current OSI version (v3.3.1) with regard to the road network. It is totally fine to not already have a solution and also the form is very free (e.g. bullet point list). The plan is to brainstorm first, and then later to consolidate and plan features for v4.0 which may also be not backward compatible.
-
Nr.1 Diverging Lane
How is this represented in OSI?
If possible, maybe just an adaption/clarification in documentation is necessary. -
Nr.2 Modeling Tunnels In OpenDrive a simple attribute of the road In OSI unclear: Three Objects (2x Wall, 1x Overhead Structure)? Similar for Pedestrianbridges and Parking houses
-
Nr.3 Modeling Objects OpenDrive „soundBarrier“ hat keine direkte Entsprechung in OSI (am ehesten „Wall“) Ebenso „gantry“, „crosswalk“ und „trafficIsland“ Umgekehrt z.B: „curbstone“ oder „construction_site_element“ Mapping von Objekttypen zwischen OpenDrive und OSI unklar. Hier können in jede Richtung (OSI → OpenDrive oder OpenDrive → OSI) Informationen verloren gehen bzw. es müssten neue Informationen „erfunden“ werden wie bei den Spurlinien. Wünschenswert: Gemeinsamer Ansatz möglich? Relevante logische Eigenschaften beschreiben. Details des 3D Modells extern lassen.
1. Topic: Road and Lane Edge
Describing a lane that has a line marking and a curbstone next to it. Required Information: Road AND Lane boundary Use Case: Driving behaviour can vary due to different road edges Prio 2, LOD 1 (logic level + dimension and position BBox level sufficient)
2. Topic: Intersection
Intersections are described as one free space currently. For agent navigation virtual lanes would be useful.
Required Information: lanes and overlapping areas regarding intersections
Use Case: Agent navigation in typical turning scenarios
Prio 1, LOD 1 (current lane describtion level for virtual lanes required, center line required)
3. Topic: Lane Types Intersections
Turing lanes classified with assigned type. In order to identify if the current lane fits the route the virtual information would be very useful.
Prio 2, LOD 2 (logic information)
4. Topic: Overlapping Areas due to Pedestrian/Cyclist Crossings:
Currently pedestrian crossings are represented as road markings not as lane. For the identification of potential conflict areas, the description as (virtual) lane would be crucial.
Prio 1, LOD 1 (Current lane describtion sufficient but required for areas like pedestrian crossings)
5. Topic: General Virtual Information for Agent Models:
Use the advantage of agent models compared to automated driving functions-> we have GT and do not need sensors to capture for example lane markings (arrows for turning) but we can built models on map interpreted map informations. (Currently: Map -> decoding -> coding -> decoding)
6. Potential Use Cases for the Future:
Einflüsse von Unebenheiten in der Straße (Bsp. Spurrillen, Schlaglöcher, Kopfsteinpflaster,..) auf die Trajektorie können auf Grund der Fehlenden Informationen nicht modelliert werden. Prio 3 (weiter in der Zukunft), Detailgrad LOD 0 (sehr hoch, lokales Mesh des Straßenabschnitts benötigt)
Das Verhalten eines Fahrers kann stark durch die Straßenbegebenheit (statische Unebenheiten, dynamisch: wassersansmmlungen bei Regen,… ) Beeinflusst werden. Um solche Aspekte in der Modellierung zu betrachten, werden detaillierte Infos benötigt. Prio 3 (weiter in der Zukunft), Detailgrad LOD 0 (sehr hoch, lokales Mesh des Straßenabschnitts benötigt)
Zukünftig sollen Agenten ihrer Trajektorie nicht nur wie auf “Schienen” folgen sondern nach der Trajektorien Planung soll ein komplexeres Dynamik Model verwendet werden können. Hierfür ist es Notwendig, dass etwaige Regler Störgrößen der Umgebung erhalten (Wie Straßenanregung, Z-Anregung, …) Prio 2, Detailgrad LOD 0 (sehr hoch, lokales Mesh des Straßenabschnitts benötigt)
Anforderung durch Fahrwerkstests des Ego Fahrzeugs? Straßenanregung benötigt!
Issues from the Harmonization-WG related to this: Centerline for other lane types? #443 => Centerlines are not defined for non-driving lanes and intersections but would be very useful, e.g. for traffic participants.
Add Longitudinal Rotation of Lane Boundaries #436 => The height and width of laneboundaries are not sufficiently defined, since the surface of the road is not described in OSI.
Boundary Points for dashed lines #539 => For dashed lines it is not possible to distinguish between gap and line. The new roadnetwork model should also have a consistent definition for this.
I will suggest some Use-Cases to be considered for the enhancement of the road network model.
As it was discussed in the meeting at Monday (5.7.2021), a Level of Detail (LOD) definition could be used for finding Use-Cases. @rockteresa and I discussed this today. For our Use-Cases we used 3 LOD Layers:
- LOD 0: Highest detail resolution: e.g. Meshes with detailed object geometries and materials
- LOD 1: Polygons on a plane with rough surface descirptions
- LOD 2: The basic route information within lanes
For my Use-Cases however, the LOD description is not valid. Most of them should be usable at all LOD levels and are more general:
- Depending on the test case, the road information can be sent at the beginning of a simulation. In this case, the network traffic can be reduced at runtime. In other test cases, my road information will be generated at runtime from a road generator. The generation is depending of the vehicle behavior and therefore, the road model must be transmitable at runtime.
- For the efficacy analysis of a driving function in a complex traffic scenario, there is no differentiation between ego vehicles and other traffic participants. Every traffic agent has to be freely parameterizable and should be able to receive every LOD of the road.
- A center line is helpful in various sitations (e.g. simple trajectory planning, the prediction of traffic participants). This can be achieved through the transmission of the center line, or a description on how to calculate the center line from the OSI data.
- There should be a simple way to calculate routes on the OSI road network description. It is currently possible, but should be considered at changing the road network model.
- For me, the possibility to transmit other road descriptions (like OpenDRIVE and OpenCRG) within the OSI road network can also be valid. This could also mean supporting various other standards.
