Here follow the meeting minutes of 2nd Autoware Maps and Map Formats Working Group Meeting, held on 24 July 2019. A recording of the meeting can be found at https://zoom.us/recording/share/YfXzQLsaDR8Vb2odu8xdFzLeu-To8jOGUH07EyKMtHE?startTime=1563962237000.
This is the list of possible PSFs
Navigation Data Standard 2.5.4 (evaluated by Punnu Phairatt )
2019.07.24 NDS review.pdf (1.7 MB)
that we considered under the following criteria:
- ease of map creation
- tooling for reading/writing/visualising/simulating
- adoption of the format
- relationship to production systems
- expressiveness (features that can be encoded)
- interchangeability with other formats
- accessibility of the format/tools etc
During the discussion that followed we did a comparative evaluation of the various formats and scored them as follows:
|Scale (1=bad 5=good)|
|Criteria||Vector Map Format||OpenDrive||Lanelet (OSM XML)||NDS|
|Ease of Creation||3 (There are multiple available tools)||1(not many tools to write map)||4 (They are node based, which is probably easier than defining continuous curves)||2 (Seems difficult to create all information)|
|Tools||3 (Read/Write for ROS software is already implemented as Autoware package)||4 (Many different tools, but majorly for simulation, not for Autonomous Driving Software)||3 (There are many OSM tools, but not much for Lanelet2)||4 (Many tools are available after purchasing license)|
|Adoption Of Format||1 (Not publicly used by other companies)||4 (Many automotive and tier-1 companies, now being standardised by ASAM)||2 (Some map vendors providing maps in Lanelet2 format)||5 (Created by major automotive and tier-1 companies, standardised under NDS Association)|
|Relation to Production Systems||1 (No plans for connecting to production systems)||3 (Not directly used in production environment but can be converted to NDS which is favored by many OEMs)||1 (Lanelet is relatively new)||5 (same reason as above)|
|Expressiveness||2 (Small amount of flexibility)||4 (traffic sign id is not clear in countries outside Germany)||3 (Does have room to extend format, but has less information compared to OpenDrive at the moment)||5 (detailed specification is closed, but is expected to be very high considering adoption and relation to production system)|
|Interchangeability||2 (MR in gitlab for conversion form Opendrive and Lanlet)||3 (bidirectional convertor to NDS)||3 (Has MR in gitlab, also lanelet1 and opendrive converter available)||2 (bidirectional converter to OpenDRIVE)|
|Accessibility||2||4||5||1 (requires license)|
The consensus of the working group is that OpenDRIVE and OSM XML are the only 2 real options. While we would use NDS, it is prohibitively expensive for the vast majority of Autoware Members and the open source community.
OpenDRIVE scored more highly than OSM XML and is preferable because of the wide adoption and closeness to production systems (through the NDS bi-directional converter). The main drawback of OpenDRIVE is the lack of tools to write XODR files, but this is easier to fix (by developing a reader/writer) than increasing the adoption and relation to production systems of OSM XML.
The proposed course of action recommended by this WG is:
Use OSM XML + Lanelet2 in the short term, with an effort to move to OpenDRIVE as the PSF.
The next topic under consideration was the map library + IO API.
Possible solutions are:
- XODR https://github.com/DLR-TS/xodr
- LibLanelets https://github.com/fzi-forschungszentrum-informatik/liblanelet
- LibLanelets2 https://github.com/fzi-forschungszentrum-informatik/Lanelet2
- Autoware.AI existing library
- Custom new library
Discussion was very short and the consensus was that Lanelet2 is the only real contender.
For the next meeting we will consider the various simulators that might be used and how maps might fit in. We will submit this as a contribution to the Autoware Simulation WG when it convenes.
The following simulators will be considered (with names of the person investigating)
The next meeting is proposed for next week and we agreed to hold it at a time favourable to the US to allow for contributions from US participants.
I propose the following 3 slots for a 90 minute meeting. Please vote for the option which would suit you best. (London, Tokyo, San Francisco). Voting will close on Sunday at midnight GMT and I will announce the time with a link to the next meeting on Monday morning.
Tuesday 11pm GMT (10pm UTC)
Thursday 11pm GMT (10pm UTC)
Friday 6am GMT (5am UTC)