OpenDRIVE Standalone Mode issues with converted OSM

[rohanb2018]

I've been having issues with using the OpenDRIVE standalone feature on OpenDRIVE files that have been converted from OpenStreetMap files (using SUMO netconvert). I am not entirely sure whether this is an issue with SUMO or with the OpenDRIVE standalone mode, but I wanted to document it in case anyone has run into similar issues. I also wonder if anyone has been able to successfully convert and deploy OpenStreetMaps files corresponding to real-world environments in CARLA.

OSM to OpenDRIVE conversion
I tested using both the OpenStreetMap export tool and the SUMO osmGet.py script to extract OSM maps, and then I used NETCONVERT to convert these OSM maps into OpenDRIVE maps. In both cases, I got the following warning:

Warning: Could not write OpenDRIVE geoReference. Only unshifted Coordinate systems are supported

OpenDRIVE standalone mode
I then tried to render the resulting xodr file with CARLA's OpenDRIVE standalone mode (in CARLA 0.9.9.4) using config.py, and as expected the CARLA server detected that the geoReference tag was missing and crashed:

WARNING: cannot parse georeference: ''. Using default values.
Signal 11 caught.

To get around this, I tried inserting a geoReference tag with fake lat/long coordinates into the xodr file, but the CARLA server still crashed.

Could it be that the OpenDRIVE files coming from NETCONVERT are just corrupt somehow? If so, is there a better way to generate OpenDRIVE files that correspond to real-world data that can be parsed by CARLA?

[germanros1987]

@Axel1092 could you take care of this?

[Axel1092]

Hi @rohanb2018,
Yes, as you say SUMO's netconvert generates corrupt OpenDRIVE files (a problem with the junction record).
We are currently working on providing a way to import OSM information into Carla integrated in our API for the next release.
This will allow you to convert OSM to OpenDRIVE and load it with the standalone mode.
About the WARNING: cannot parse georeference: ''. Using default values. warning, it only indicates that there is no global localization information in the OpenDRIVE file but Carla does not need this information to run the simulation.

[sp062]

How to Export .xodr from SUMO netconvert. Have imported OSM file but how to get xodr file for it?

[Axel1092]

@sp062 netconvert produces broken OpenDRIVE which will crash when loading into carla. If you compile Carla from source you will find a new feature to convert OSM to XODR files. You can also use the packages here: https://github.com/carla-simulator/carla/blob/master/Docs/download.md#pre-release-0910 which also have these feature enabled but you need additional dependencies in linux (sudo apt-get install libxerces-c-dev)

[TKeutgens]

Hi @Axel1092 , I love the new feature. Unfortunalety if I follow the tutorial (https://carla.readthedocs.io/en/latest/tuto_G_openstreetmap/) a warning is thrown.

Warning: Could not write OpenDRIVE geoReference. Only unshifted Coordinate systems are supported (offset=10805307.92,-4140722.51)

How should the input data look like to generate a georeferenced OpenDRIVE file?

[Axel1092]

Hi @TKeutgens, right now that feature is not supported, we are working on expanding this feature to add new projections to include geolocation information. A workarround for now is to include the geolocation information yourself into the resulting opendrive file.

[TKeutgens]

Hi @Axel1092 thanks very much for your support! Is there an example or step-by-step guide for the workarround? I tried adding the geoGeoreference tag into the ODR file. As lat_0 and lon_0 I added the minlon and minlat parameters of the OSM file. But the results don't match my georeferenced satellite image. It also seems like there is a roation error in the ODR file. Do you have any information on this?

[lucasnmatias]

Hi, I'm also working with conversion from OpenStreetMap to OpenDrive and to import it to Carla. How can I use this new feature? I've downloaded the pre-release version 9.9.10 but I don't know how to use python API from this pre-release, when I run a python code using carla lib I just get:

Traceback (most recent call last):
  File "config.py", line 28, in <module>
    import carla
  File "/home/lucas/.local/lib/python3.7/site-packages/carla/__init__.py", line 8, in <module>
    from .libcarla import *
ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory

[Axel1092]

@lucasnmatias it seems like you are missing a specific library required for running carla in your system. Here are some of the libraries you may be missing: sudo apt-get install libpng-dev libtiff5-dev libjpeg-dev libxml2-dev libxerces-c-dev

[Hanjinchao]

so, I got this osm converter working, but when I use road-runner review the xodr file, seems like the map was
distorted, any suggestions?

[Axel1092]

@Hanjinchao, can you import the map in carla with the standalone mode? python3 config.py --osm-path=path/to/osm in the util folder and check if the map is still distorted please?

[Hanjinchao]

so....for some reason my carla0.9.10 build does not work properly, I tried on Linux build and win build, the windows carla unreal editor does not show up, it will go straight to crash. For Linux, the Carla unreal editor will crash if I play it, so I can't really test it with the later version, but with carla0.9.9 I try to use the config.py -x <generated_from_osm.xodr>. it does not load anything

[Hanjinchao]

also.....is there any support for left-hand model? I am located in Japan, the osm data is left-hand by default

[Axel1092]

@Hanjinchao Do any messages show up with the crash? If the unreal crash report pops up I would like to take a look at it in order to help you to solve this issue.
The OSM support is for 0.9.10 on. And we do support left-hand traffic at the moment.

[Hanjinchao]

I suspect I got something wrong when I build the 0.9.10 carla, but the same result showed after I rebuild Carla.
here is the message when I try to run unreal editor:

BuildCarlaUE4.sh: line 151: 10623 Killed ${GDB} ${UE4_ROOT}/Engine/Binaries/Linux/UE4Editor "${PWD}/CarlaUE4.uproject" ${RHI}
Util/BuildTools/Linux.mk:7: recipe for target 'launch' failed
make: *** [launch] Error 137

That's strange, I got 0.9.9 version running on the same machine, and it's all fine.

[Axel1092]

@Hanjinchao It seems that the ue4 editor is crashing (I think it is due to not enough memory could you share the system specs?).
Could you share the rest of the console log from make launch command if possible in order to be sure of the problem?

[Krxtopher]

I can confirm that I experience the same projection distortion that @Hanjinchao reported above even when I just load an OSM file into Carla directly using the Python script python config.py --osm-path=map.osm . I describe the issue in detail and include images in this Carla forum post.

Any insight into whether this issue can be worked around and specifically how to do it?

[thillRobot]

I am having a similar problem while trying to follow the tutorial here
for generating a map from OpenStreetMap for CARLA. I see a similar warning when converting the .osm file from OpenStreetMap to .xodr for CARLA with the sample code provided in the tutorial. I am using CARLA 0.9.10.1.

Warning: Could not write OpenDRIVE geoReference. Only unshifted Coordinate systems are supported (offset=7685454.90,-4019034.71)

I overlooked the warning at first, but the map does not load properly in the next step using python config.py --osm-path=map.osm. I receive the following output.

Converting OSM data to opendrive
No nodes loaded.

Any information would be greatly appreciated.

[thillRobot]

I have solved my problem. The solution is here in the CARLA Docs. My map is loaded properly when I use the -x which makes sense for the .xodr file. I may have misread the first tutorial I mentioned in my previous comment.

This command works for me.

python3 config.py -x opendrive/TownBig.xodr

I realize that this may have been off topic...

[thillRobot]

Now that my map is loading, I can confirm that I am also experiencing the map distortion. I tested today with carla:latest.

Update:@Krxtopher, I have found a work around the distortion issue by using osm2xodr to convert which you can find here on github.

[EchoYJJ]

Now that my map is loading, I can confirm that I am also experiencing the map distortion. I tested today with carla:latest.

Update:@Krxtopher, I have found a work around the distortion issue by using osm2xodr to convert which you can find here on github.

Hi! I am also experiencing the map distortion. I have used the method you have recommended by running OSM2XODRconv.py. However, it shows "AttributeError: 'Namespace' object has no attribute 'xodr_pathen'".
I don't know if I get it right.
Waiting for your reply, thank you!

[thillRobot]

I do not recognize that error, but I do notice that your script is called OSM2XODRconv.py. I used a script from osm2xodr called main.py to convert the map instead. Have you tried using this?

[Krxtopher]

@thillRobot , I tried the osm2xodr project that you mentioned, but the .xodr file it produces (for a very simple OSM file) crashes Carla when I try to load it into the running simulation using Carla's config.py script. I don't have this problem when loading other .xodr files this way. Do you have any insight into what might be wrong? I noticed that the output file that osm2xodr produces has no <header> elements (including projection information) which seemed suspicious to me.

Would you be able to provide me with a sample OSM file that you know works with that converter tool so I can better troubleshoot the issue?

[thillRobot]

@Krxtopher, I would be happy to share. You can get the .osm and the resulting .xodr files I have tested here at my github. I recommend starting with map1 because it is smaller and it is easier to find the road in spectator view. In the larger map0, I had to fly around to find the map. It reminded me of flight simulator.

Let me know if you get it going.

[EchoYJJ]

@thillRobot, thanks a lot for your advice. I successfully realized your example in SUMO and no distortion appears. Also, I can use osm2xodr.py to convert my osm to xodr. But when I use CARLA's netconvert_carla.py to convert xodr to net, it shows the error below:
Error: invalid byte '?' at position 1 of a 1-byte sequence
In file 'D:\HHYtest\test.xodr'
At line/column 879/70.
But, after checking my file, it doesn't exist '?' at that position.

Also, I noticed that the 'topomap.png' in main.py seems specific for the example map. Whether should I renew the 'topomap.png' for my own osm, and by how.
Looking forward to your reply, thanks!

[thillRobot]

You are welcome. It is good to hear that you got it working. I admit I am learning this as I go, and I do not have any information about net files. I have not encountered this file type in my project.

Regarding topomap.png, for my tests I left the topographieKartenPfad = unaltered, and the script still ran without errors. I also want to add custom topography, but there are different ways to do this. Have you looked at josm? I am working on my documents for using these different map files this week. and you can see them in the github I shared above. I am writing those notes for me, so use them at your own risk.

[EchoYJJ]

I really appreciate your help. Good luck with your study!

[thillRobot]

OK, thanks. This is consistent with what I have seen. The OpenDRIVE map works after exporting from RoadRunner only if the junctions are intact, also there may be other funny issues that I have not seen.

[hongyuli]

@Axel1092 I have an interesting finding:
(1) when exporting the same OpenDrive file from RoadRunner, CARLA can only work if I deselecting the 'export scene origin reference' option. If I chose to 'export scene origin reference', CARLA will have the following error.

Signal 11 caught.
Malloc Size=65538 LargeMemoryPoolOffset=65554
CommonUnixCrashHandler: Signal=11
Malloc Size=65535 LargeMemoryPoolOffset=131119
Malloc Size=127232 LargeMemoryPoolOffset=258368
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.
Segmentation fault (core dumped)

(2) I also observe the same error when I use the OpenDrive file generated by netconvert in SUMO.

So, I'm wondering whether CARLA has the assumption that the OpenDrive file needs to be centered before using config.py feeding into CARLA. Is it possible that the OpenDrive file generated by netconvert is not corrupted but just not centered?

[JHMeusener]

Hello, if anyone is interested, i wrote a small workaround for the projection-issue with the Carla OSM Converter.
Carla Projection Workaround for OSM to XODR Conversion

[Axel1092]

@hongyuli the problem with netconvert is that junctions are broken which causes our parser to crash due to references to non-existing roads in the OpenDRIVE file. My guess is that with some options RoadRunner may be able to repair these issues providing a working OpenDRIVE.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[namdre]

I case anyone is still interested: SUMO version 1.12.0 supports import and export XODR with shifted geo coordinates.
@Axel1092 can you provide an example OSM file that illustrates invalid xodr generated by netconvert? I'd very much like to fix this.

Generally speaking, If you find any issues with SUMO tools, I invite you to open an issue at https://github.com/eclipse/sumo

[thillRobot]

@namdre, I can produce an example if someone else does not have one readily available. It will have to wait until later tonight or tomorrow.

[thillRobot]

@namdre, here is a small an example of the conversion process using netconvert from sumo (stable - installed 02/24/2022). Later I can add some examples of how is appears in Roadrunner and CARLA.

https://github.com/thillRobot/carla_simulator/tree/master/maps/Campus03

[namdre]

@thillRobot Thanks. I'm afraid I won't be able to solve this problem on the sumo side without additional information from the carla devs (except for diving into the carla parser code myself).
So far I haven't seen a Carla error message that points to the problem.

@Axel1092 can you confirm that the netconvert-generated xodr has been working with Carla at some point? At least the whole OSM2ODR part of Carla which uses sumo/netwrite version 1.8.0 as a library seems to suggest a working toolchain.

• Is the problem limited to specific OSM input?
• Is the problem confined to newer version of netconvert?
• Do you have any further details on the nature of the faulty xodr?

FYI, SUMO users have report success in using netconvert-generated xodr with RoadRunner, VTD and Esmini. The classic odrViewer from VIRESalso loads netconvert-xodr.

[gregor-ovsenjak]

@Axel1092 I think that the error You are refering to is mentioned here eclipse-sumo/sumo#9637 (comment) . I encountered the same problem when running in Esmini. This issue has been since fixed. Of course this is just my guess .

[namdre]

@gregor-ovsenjak The error you mentioned is old and hence should have always affected the carla-OSM2ODR library.

[namdre]

@thillRobot Please try the latest github version of netconvert. As @gregor-ovsenjak reported, the latest fixes on the sumo side permit loading of his netconvert-generated xodr with Carla.

[namdre]

The git clone must be compiled. You can get nightly-binaries via pip install -i https://test.pypi.org/simple/ eclipse-sumo Am Fr., 11. März 2022 um 00:13 Uhr schrieb thillRobot < ***@***.***>:

…

@namdre <https://github.com/namdre>, previously I have used a system wide installation of sumo from apt, but I just cloned the latest sumo from github. Do I need to compile to use this netconvert? — Reply to this email directly, view it on GitHub <#3009 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPTS5WE3SVSUBUKXKTKTGTU7J6YZANCNFSM4OMRWPSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[thillRobot]

Thanks @namdre. I got that compiled and converted the map I shared previously with the latest netconvert. I am now running a test in standalone mode, and the map looks good (link to image). However, there is an error that appears after loading the map that I am not familiar with.

This continues with hundreds of more lines of the same warning.

WARNING: cannot parse georeference: '
 +proj=utm +zone=16 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
'. Using default values. 
WARNING: Traffic sign 203369851_7 overlaps a driving lane. Moving out of the road... 
WARNING: Traffic sign 203369851_6 overlaps a driving lane. Moving out of the road... 
WARNING: Traffic sign 203402905_4 overlaps a driving lane. Moving out of the road... 
WARNING: Traffic sign 203369839_7 overlaps a driving lane. Moving out of the road... 
WARNING: Traffic sign 1994268551_7 overlaps a driving lane. Moving out of the road... 

I need to improve the world to do a better test. The cars tend to fall off the map very quickly in standalone mode so the test is not representative. Also, I think the cars that fall off into infinity may cause problem.

Further, after closing the processes, CARLA server will not start again without restarting the GPU (I think). Here is what I see when I try to restart the server

4.26.2-0+++UE4+Release-4.26 522 0
Disabling core dumps.
LowLevelFatalError [File:Unknown] [Line: 136] 
Exception thrown: bind: Address already in use
Signal 11 caught.
Malloc Size=65538 LargeMemoryPoolOffset=65554 
CommonUnixCrashHandler: Signal=11
Malloc Size=131160 LargeMemoryPoolOffset=196744 
Malloc Size=131160 LargeMemoryPoolOffset=327928 
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.

This may be related to my outdated 9.12 (Python3.6) version of CARLA, but I am not sure. I need to update.

[namdre]

The Traffic signs are supposed to be over the driving line (zOffset="5"). I'm not sure how to distinguish the location of the "lamps" from the position of the pole, but the OpenDRIVE documentation seems to imply that <signal> is for the lamps ("signs that can change their state dynamically")

What is causing cars to "fall of the map"?

W.r.t to CARLA server not starting again, I can just hope that this is unrelated to the loaded map.

[thillRobot]

I am not sure about the signs. I have not looked at that much. I have tested adding them in RoadRunner and that seems to work.

The cars fall off the map because in 'standalone mode' (load raw converted xodr into CARLA) there is is not a sidewalk or walls, so the cars accidentally fall off the road at turns. I remember there being a setting to make walls, but I cannot remember where. I think it is in the conversion using CARLA instead of netconvert.

Last night I downloaded and updated CARLA 0.9.13. After building I will work on another test. RoadRunner and/or Blendr can be used to add terrain which will fix the falling off the map issue. I'll keep you updated, @namdre.

[thillRobot]

@namdre I have 0.9.13 built now with the PythonAPI working in Python3.8. Its going to take some more time to get the map ready to test. I will be away for a week, but Ill try to run a thorough test when I return.

[debipe20]

python3 config.py -x opendrive/TownBig.xodr

I ran "python3 config.py -x opendrive/TownBig.xodr". Unfortunately got the following.
"load opendrive map 'TownBig.xodr'.
map not found"

any suggestions?

[buntyk48]

Hello all,

I would like to use the file edited by NETEDIT in Carla.

I tried using NETCONVERT tool to get the .xodr file.

netconvert -s osm.net.xml --opendrive-output osm.xodr --sidewalks.guess --walkingareas

There were also many warning messages that appeared.

But Carla crashed instantly with the following error:

4.26.2-0+++UE4+Release-4.26 522 0
Disabling core dumps.
WARNING: cannot parse georeference: ''. Using default values. 
Signal 11 caught.
Malloc Size=65538 LargeMemoryPoolOffset=65554 
CommonUnixCrashHandler: Signal=11
Malloc Size=131160 LargeMemoryPoolOffset=196744 
Malloc Size=131160 LargeMemoryPoolOffset=327928 
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.
Segmentation fault (core dumped)

Ps: This osm.net.xml file was converted from .osm file using NETCONVERT tool.

I have used that carla.OSM2ODR tool to get .xodr file and that worked fine for me. I went through the whole thread but could not figure out the solution.

[thillRobot]

It looks like a memory issue (possibly OOM). Have you watched the system resources while the crash happens?

[buntyk48]

I didn’t check at that time but I use the same computer regularly and have never come across such issues. But I can check it again tomorrow.
Thanks.

[buntyk48]

It seems like there is no issue with the memory up to my understanding.
I checked other .xodr files converted from .osm again and it worked fine but this .xodr file converted from .net.xml using the netconvert tool.
I even tried running a co-simulation between Sumo and Carla using other network files.
Actually, I have no clue how to export pedestrian paths as well from OSM. So, I edited the file using NETEDIT and now I am not able to load that file in Carla.

[BestSonny]

@buntyk48 I encounted the same issue. Do you have any hint on how you have fixed it using net.xml? Thanks

[buntyk48]

@buntyk48 I encounted the same issue. Do you have any hint on how you have fixed it using net.xml? Thanks

We don't have any option to use the networks edited or generated by Netedit in Carla. We have to use its own tool OSM2XODR or other tools mentioned in their documentation.

For further information check out this documentation Page:
https://carla.readthedocs.io/en/latest/tuto_G_openstreetmap/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.