Autoware Map Data and Formats working group: Call for participation

Archive Autoware
1

Following on from the announcement about working groups for the Autoware Foundation , the announcement of the reference platform working group and the Autoware Working Group, I’d like to announce the Autoware Map Data and Formats Working Group.

This working group will be led by myself, @simon-t4 and @mitsudome-r. The purpose of the working group is to consider the various options for map formats and define the architecture within Autoware to consume the maps. The working group’s remit will cover the following topics at least:

  • identify the physical storage format (map format) that Autoware should support considering factors such as
    • ease of creation
    • adoption of the format
    • relationship to production systems
    • expressiveness (features that can be encoded)
  • consider the library(ies) to read and write to that format to supply relevant data (map-server) to
    • the perception modules (e.g. traffic light detection, road markings etc)
    • path planning modules (routing)
    • localisation modules (for those localising using techniques other than NDT).
  • propose an architecture to support these functions including message definitions
  • …

We will begin by meeting every two weeks. The first meeting time is Wednesday, July 17, 2019 2:00 PM Europe: London (see below for the meeting information). The meeting will last for 30 minutes.

The regular time is to be decided based on who wants to participate in the working group, so if you are interested then speak up here even if you can’t join the first meeting!

Most of our coordination will be via GitLab and on discourse. The teleconferences will mainly be used to catch up on progress overviews and discuss tricky issues that are hard to do via text.

We are open to all, no matter your affiliation or skill set and we welcome your views and contributions.

Brian Holt is inviting you to a scheduled Zoom meeting.

Topic: Autoware Map Data and Formats Working Group
Time: Jul 17, 2019 02:00 PM London

Join Zoom Meeting

One tap mobile
+493030806188,489169590# Germany
+493056795800,489169590# Germany

Dial by your location
+49 30 3080 6188 Germany
+49 30 5679 5800 Germany
+49 69 7104 9922 Germany
+1 408 638 0968 US (San Jose)
+1 646 558 8656 US (New York)
+81 3 4578 1488 Japan
+81 524 564 439 Japan
+61 2 8015 6011 Australia
+61 8 7150 1149 Australia
+43 670 309 0165 Austria
+43 72 011 5988 Austria
+32 2 290 9360 Belgium
+32 2 588 4188 Belgium
+33 1 7037 9729 France
+33 7 5678 4048 France
+972 3 978 6688 Israel
+972 55 330 1762 Israel
+64 4 886 0026 New Zealand
+64 9 801 1188 New Zealand
+44 203 481 5237 United Kingdom
+44 203 966 3809 United Kingdom
+44 131 460 1196 United Kingdom
+44 203 051 2874 United Kingdom
Meeting ID: 489 169 590
Find your local number: Zoom International Dial-in Numbers - Zoom

2 Likes
2

To begin with, I propose that interested parties read the following threads and resources prior to the meeting if possible:

@gbiggs do you know where we can find links to

  • Lanelet2 presentation by Parkopedia at Autoware@IV2019 workshop
  • Lanelet2 presentation by Tier4 at Autoware@IV2019 workshop
  • Carla + ROS + Autoware presentation at Autoware@IV2019 workshop
2 Likes
3

I am sharing some analysis between OpenDRIVE and Lanelet2 Public: OpenDrive vs Lanelets - Google Docs

We at Ridecell-Auro use Lanelet2 in our stack as the vendor independent format and to support importing and exporting to different common map formats, and are building support for OpenDrive and would love to share the outcome or work together with other contributors.

1 Like
4

Hello, I would like to join this working group, please include me in any future conversations.

5

I would like to share the idea about custom tags that we have to define to use Lanelet2 in Autoware.

I created this after investigating how current vector map information is used in Autoware and looked for missing information in Lanelet2 format.

I also want to discuss about the ROS message for lanelet2 data. This must be done in order to integrate Lanelet2 into Autoware.

6

Hi everyone,

Thank you to those who joined the meeting today.

Here follows the meeting minutes:

  • We need to consider the various use cases for maps. At minimum these are the use cases
    • Autonomous Valet Parking (Autoware.Auto reference use case)
    • On-street driving
      • < 40km/h

      • 40km/h (need to consider surface characteristics, road camber etc.)

Ideally we would have a single map format that would work for all the various use cases.

Our first discussion was to list the various possible Physical Storage Formats (PSF) and consider the pros and cons of each according to 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

This is the list of possible PSFs that we will consider for the next meeting:

  • OpenDRIVE 1.5 (to be evaluated by @Angelo_Mastroberardi )
  • OpenStreetMap XML (Lanelets variety) (to be evaluated by @simon-t4 )
  • Navigation Data Standard 2.5.4 (to be evaluated by Punnu Phairatt )
  • Aisan Vector Map (to be evaluated by @mitsudome-r )

Our next meeting will be on Wednesday, July 17, 2019 10:00 AM Europe: London (see below for the meeting information). The meeting will last for 90 minutes.

Brian Holt is inviting you to a scheduled Zoom meeting.

Topic: Autoware Map Data and Formats Working Group
Time: Jul 24, 2019 10:00 AM London

Join Zoom Meeting

One tap mobile
+496971049922,130749793# Germany
+493030806188,130749793# Germany

Dial by your location
+49 69 7104 9922 Germany
+49 30 3080 6188 Germany
+49 30 5679 5800 Germany
+1 929 436 2866 US (New York)
+1 669 900 6833 US (San Jose)
Meeting ID: 130 749 793
Find your local number: Zoom International Dial-in Numbers - Zoom

7

Thank you for arranging the next meeting.
For the meeting time, is it possible to push it back an hour?
I am occupied until 11AM(London time) on 24th.

8

Hi Mitsudome-san,

I’m happy to move it back by an hour. Does anyone else have any views or comments on time?

Regards
Brian

9

We would be happy if it is more convenient for PDT

image
image1002×116 18 KB
, or we will just work off the meeting notes

10

Hi Jit,

Thanks for your comments. As you will no doubt know, it’s always challenging finding a suitable meeting time when working across USA/Europe/Asia.

image

The current time slot was chosen because so far we’ve only had interest from Europe and Japan, therefore it made sense to choose times that worked best for them. With the request to include USA I suggest that start a rotation, much like what the Autoware TSC does.

@mitsudome-r @simon-t4 do you have any thoughts or comments?

11

Hi Brian,

yes a rotation through the time zones sounds like a good compromise. Perhaps keep the scheduled time on this occasion and then give the USA participants preference for next meeting?

For tomorrow, I am open to scheduling it later, but it seems pushing it back long enough to make a difference in PDT (8AM PDT ー24:0０Tokyo) would be difficult.

12

Hello,

I would like to participate in this working group. Is there anything I need to do beyond attending the next meeting?

Thanks,
Michael McConnell

13

@Brian_Holt
Starting a rotation sounds good to me as well.

For tomorrow, I am available after 11AM London(7pm Japan). Perhaps we could change it to 2PM or 3PM London just like the first meeting. It’s still early in the morning in PDT, but I think it is better than 11AM. If we are changing the meeting time, then I would like to know it before tomorrow noon in Tokyo.

14

Hi Michael,

Great to have you on board! There is nothing more required than turning up for the meeting. The minutes will be posted afterwards for those who can’t attend.

Regards
Brian

15

Hi @mitsudome-r,

Let’s keep it now at 11am UK time (7pm Japan time) because I fear that if we change it too many times people will get confused and we have have low turnout to the meeting.

Regards
Brian

1 Like
16

Thanks for the clarification. See you there!

17

As our commitments are limited let’s not change time to support us, I would still expect some more meeting notes so that we can collaborate

18

Hello.

I’d like to summarize this WG’s current status so that make discussions more beneficial.
I didn’t refer to mass production level HDMap like NDS because I think it’s not the stage yet.

Would you confirm the content and let me know if there are any points to be corrected?
Thank you.

Main Goal

Define the HDMap architecture for Autoware.Auto

  • Physical Storage Format
  • Internal Map Model
  • HDMap API
  • Map Creation / Editor
  • HDMap Conversion / Supporting Various HDMap Formats
  • Integration with Simulators
  • Computational Cost / Resource Usage

Sub Goal

Get independent of AISAN proprietary format in Autoware.AI

  • Replacing AISAN with Lanelet2 in Autoware.AI v1.13

Replace Autoware.AI with Autoware.Auto or use them together

  • HDMap API Compatibility between Autoware.AI and Autoware.Auto

Current Status

Physical Map Storage Format

  • OpenDrive is the best format.
    • But Map Creation is not considered.
  • Lanelet2 is temporarily used and will be replaced with OpenDrive later.
    • But since the original Lanelet2 doesn’t meet Autoware’s requirement, some extensions are required.

HDMap API

  • Whether using pub/sub or service.
  • Whether sending structured API or the whole map.
  • These should be considered using AVP use case.

Internal Map Model

  • Currently, Lanelet2 is the only solution.
  • But we might need to improve/re-implement it so that it would be safer.

Map Creation / Editor

  • Lanelet2

    • JOSM
    • Tier IV Vector Map Tool
    • Other GIS Tools

  • OpenDrive

    • Trian3d
    • RoadRunner
    • VIRES Road Network Editor

As for Lanelet2, since it is too extendable, we might need to restrict the format and define XSD-like document.

HDMap Conversion / Supporting Various HDMap Formats

As for OpenDrive ↔ Lanelet2 conversions, Ridecell-Auro created a slide: Public: OpenDrive vs Lanelets - Google Docs

OpenDrive → Lanelet2 is easy, but Lanelet2 → OpenDrive is a bit difficult.

As for other formats, since Lanelet2 is a simple format, any format can be supported if the users prepare a converter by themselves.

Integration with Simulators

  • Since most simulators support OpenDrive, if we prepare OpenDrive Map then we can integrate.

Computational Cost / Resource Usage

  • We have to consider these aspects due to safety requirements in the future.

  • This is strongly related to Internal Map Model.

  • e.g. Full search is tolerable or indexing is necessary.

Replacing AISAN with Lanelet2 in Autoware.AI v1.13

  • Sending the whole map using pub/sub is a least-cost solution, but it’s probably not the best solution.

HDMap API Compatibility between Autoware.AI and Autoware.Auto

  • Since the solution in v1.13 would be quite different from the ideal architecture of Autoware.Auto, we need to consider how to make them compatible.

Milestone

I think this is not clear and should be determined.

1 Like