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 . 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!

[germanros1987]

@Axel1092 is this problem solved?

[thillRobot]

No, I do not think so. I am using netconvert, and it seems to work. The junctions appear as they have imported correctly into roadrunner, and they can be exported to .xodr. However, after I project the scene onto an elevation map, I have to repair the junctions manually in roadrunner. It would be nice to have elevation and have the junctions handled automatically.

I realize the junction issue may be off topic. To clarify, I am still seeing the distortion issue in 0.9.11.

[Axel1092]

@thillRobot, the issue regarding the map distortion is due to the lack of full projection parameters when importing OSM data. This is still work in progress. netconvert does indeed have all the projection methods you need but it generates broken OpenDRIVE files which results in the crash in CARLA.

[TKeutgens]

@Axel1092 could you perhaps share an example on how to manually include the geolocation information into the generated opendrive file?

[Axel1092]

Sure, you can open the OpenDRIVE file with any text editor, the header of the file should look something like this:

<header revMajor="1" revMinor="4" name="" version="1" date="2020-07-29T12:17:19" north="2.8349990637833574e+1" south="-3.5690998535156251e+2" east="4.2268105762411665e+2" west="-2.8359911988457576e+1" vendor="VectorZero">
<geoReference>
+proj=tmerc +lat_0=0 +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +geoidgrids=egm96_15.gtx +vunits=m +no_defs
</geoReference>

inside the <geoReference> you can insert your georeference information. You can find more infor regarding the OpenDRIVE structure here: https://www.asam.net/index.php?eID=dumpFile&t=f&f=3796&token=e2cea172773a1579ff15742846221ea21f80cd2f

[TKeutgens]

Perfect thank you very much!

[thillRobot]

@Axel1092, Thank you for the information. Can you tell me what the crash looks like, or is there an issue on here that I should read? I am able to run the simulator with my level and use spawn_npc.py and manual_control.py, but I have not stress tested it much.

[thillRobot]

I should add that I am importing the .xodr that was exported by roadrunner into CARLA (not the one generated by netconvert).

[Axel1092]

@thillRobot you should see a regular segmentation fault error if you load an OpenDRIVE from netconvert. When importing from RoadRunner you should have no problems (unless the map is broken or something happened during the export process). I imagine that importing the OpenDRIVE map from netconvert to RoadRunner also has its funny issues as the file is indeed broken.

[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[bot]]

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 https://github.com/eclipse/sumo/issues/9637#issue-1062250773 . 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 https://github.com/carla-simulator/carla/issues/3009#issuecomment-1064602584, 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.