Problems Using Netconvert to change opendrive map to sumo

[RichardXIA001]

Hello,

I'm a student working on autonomous driving, currently focused on converting an OpenDRIVE map to a SUMO map using the netconvert function within this project. However, the converted SUMO map doesn't match our expectations. For instance, the network relations appear highly distorted as we see in netedit.

What we obtained:

Expected results:

When we are running netconvert function, we also notices there are warnings like:

1. Warning: Found sharp turn with radius 1.89 at the end of edge '-64#0'.
2. Warning: Lane '-27_0' is not connected from any incoming edge at junction '365'.
3. Warning: Intersecting left turns at junction '101' from lane '-67_0' and lane '-58_0' (increase junction radius to avoid this).
4. Warning: Connection '-12_1->-40_0' has a grade of 12.81%.
5. Warning: Edge '-24#0' has a grade of 193.53%.

We suspect that we might need to adjust the input arguments for netconvert, but we're unsure about the correct parameters. Could you please provide some guidance?

Attached is the map we're using. You can run the provided .sh script to check the SUMO map. maps.zip

SUMO version: 1.19.0

Operating system: Ubuntu 22.04.3 LTS

Thanks in advance for your assistance.

[namdre]

The initial view in netedit doesn't yet have the computed junctions and internal edges. Press F5 to get a more complete understanding of the geometry (or look at the network in sumo-gui). The large size of the intersections reflects xodr input. The junction shape starts exactly where an OpenDRIVE road ends and a connecting road begins. The grades aren't quite as steep in the network version that you attached (Warning: Edge '-9#2' has a grade of 96.59%. is the biggest I see) but they are still unrealistically large. This might be a bug or a problem with the input data

[namdre]

Thanks for your prompt response! Here is the view of converted map in netedit after I pressed F5: image.png (view on web)

Compared with our expected map, we noticed that there were several problems in conversion:

1. Incorrect Computation of Lane Edges: The directional signs in the converted map appear chaotic and unrealistic compared to the expected layout. Expected: img_v3_02as_15432d1e-5686-4e23-b557-d5890f7ed30h.jpg (view on web) Converted result: img_v3_02as_53ba14e3-f859-45b6-a1bc-04fc4480050h.jpg (view on web)

2. Inaccurate Scaling of Roads: The radius of converted roundabouts is significantly larger than expected, and in some areas, the lane width is also larger, causing the disappearance of empty spaces between roads. Expected: img_v3_02as_89bd0aa5-e316-495d-af8b-5baaf59d960h.jpg (view on web)

Converted results: img_v3_02as_62344816-c8b0-45bc-8826-8390a3c84f8h.jpg (view on web)

3. Presence of Nonexistent Junctions and Roads:The converted map includes junctions and roads that do not exist in the expected layout. Expected: img_v3_02as_5b88434b-527d-4b3f-b007-013d99c8e9ah.jpg (view on web) Converted result: img_v3_02as_e007058a-f3cf-40c1-9e4f-c2c02248216h.jpg (view on web)

Now I want to know how to address these issues. Additionally, I'm curious about the meaning of the grades associated with the conversion process and how to check the input .xodr file.

Any guidance on these topics would be greatly appreciated!

1. the directional signs are not intended to perfectly capture reality. They are shown in sumo-gui at the start of every edge (i.e. if an edge is split to model changed speed or width), whereas in reality they would only show up at intersections.

2. the black part that look like an oversized roundabout are computed intersection shapes which do not influence the simulation. If you press Ctrl+J in sumo-gui you can better see the underlying road topology. Please note that all connecting roads (called "internal lanes" in SUMO, id always starts with ":") are rendered at 50% of their actual width to reduce clutter.

3. the roads and junctions are part of the xodr and also shown by the online viewer:

4. the grades are computed based on the change in z position along one of the piecewise linear geometry segments in the sumo network model.

[dhogueAltF4]

Thank you namdre for the clarification. I have a follow up question. Do you know why sumo net_convert is rendering this area with jagged lane maneuvers? When we load it in odrviewer and CARLA the lane maneuvers look smooth.

[namdre]

the network has a curved "reference line" to model the changing use of the center lane (sumo would expect a clean cut-off between having the center lane used for one or the other direction.

[dhogueAltF4]

Thank you, @namdre. I updated our OpenDrive file based on your suggestion and noticed significant improvements to the Southwest left turn lane I mentioned earlier. I also applied your suggestion to a Northeast left turn lane experiencing similar issues. While this section of the map has improved, I observed an unwanted output in the top left corner of this road segment. Have you encountered this before? Are there different parameters I can use in NetCovert to resolve this, or could it be related to the OpenDrive file itself?

SW Left Turn Lane Fixed! :tada:

NE Left Turn Lane Before

NE Left Turn Lane After

[namdre]

Can provide the xodr file (or preferably something minimal that just contains the problem area from your screenshot)?

[dhogueAltF4]

Here is the area in odrviewer and the attached OpenDrive file OpenDrive File

[namdre]

I'm still seeing the problem of a curved reference line mentioned earlier. Road 66: is quite short and the middle lane switches from one direction to the other with a continuous transition in lane widths. The best way to model this in SUMO is to cut the road into two parts and have the width transition within a junction (marked in red):