[proposal] Crossing UTM and MGRS boundaries to address larger operational areas

[kminoda]

Introduction

The current Autoware systems face several challenges related to maps, limiting the size of the operational range and regions of operation. In particular, there is no support for switching coordinates when crossing MGRS or UTM boundaries.

• MGRS is a coordinate system defined in approximately 10km x 10km grid, on which Autoware bases its operation. As the operating range expands or the number of Autoware adoption projects increases, the likelihood of crossing these boundaries inevitably emerges. There are also restrictions that some municipalities located on the boundaries of MGRS cannot be traversed at all.
• The UTM coordinate system is a larger flat map that encompasses MGRS, and cases crossing this UTM boundary are also unable to be handled. The potential is lower than MGRS because of the large area, but it can still be a factor limiting the scalability of Autoware.

Goals:

• Enable Autoware to operate seamlessly across MGRS boundaries.
• Enable Autoware to operate seamlessly across UTM boundaries.

Non-Goals:

• Enable Autoware to operate seamlessly across any range on Earth.
  • According to internal research at TIER IV, implementing a coordinate origin shift or relative coordinate system would be necessary to achieve these non-goals. However, these are expected to result in substantial implementation and maintenance costs, so they are out of the scope of this project.

Design Overview

Projection method

In this proposal, we will support some other projection types other than UTM. As long as we use UTM, we cannot handle operating areas near the boundaries of UTM zones.
Therefore, in this proposal, we will support some additional projection method to project the Earth onto a map. The current candidates are as follows:

1. Transverse Mercator projection: Instead of UTM, this method uses arbitrary longitude as the central meridian to perform a projection similar to UTM.
2. Oblique Mercator projection: Unlike the Transverse Mercator projection, this method creates a Mercator map based on the center of the operation range.
3. Stereographic projection: This is a conformal map projection method that is different from the Mercator projection. It might have some advantages in terms of distortion.

Note that GeographicLib does NOT support stereographic projection with arbitrary center points on the Earth surface (or namely Oblique Stereographic Projection), and thus we are planning to use other library such as GDAL (of course we are going to hold some simple experiment to make sure that the difference between those two libraries do not exists or negligible).

Modification in Autoware

Given a map with arbitrary projection types, the Autoware should start with the projection types passed around to all the nodes that require that information.
Thus, we identify that the major changes are three fold:

• Add projection type info in map metadata
• Add map_projection_loader (name TBD) that loads the above projection type
• Update some nodes that converts between global and local coordinate

Add projection type info in map metadata

Autoware will only accept a map that has its projection type. It is open to discussion where to put the information, but one good example would be to make projection_info.yaml.

├── lanelet2_map.osm
├── pointcloud_map.pcd
├── pointcloud_metadata.yaml
└── projection_info.yaml

In case of MGRS coordinate,

# projection_info.yaml in case of MGRS
map_projector_type: MGRS
mgrs_grid: 54SUE

In case of stereographic projection for example,

# projection_info.yaml in case of stereographic projection
map_projector_type: Stereographic
center_latitude: 35.624378
center_longitude: 139.742465

Add map_projection_loader (name TBD) that loads the above projection type

We also add map_projection_loader node that loads the above projection_info.yaml file and publishes it as a ROS 2 topic (latched).

Update some nodes that converts between global and local coordinate

Some nodes in Autoware, namely gnss_poser and ADAPI, converts between global and local coodinate. For example, gnss_poser converts geoid coordinate (lat, lon) to local coordinate (x, y).
These nodes should first subscribe the above map_projector_info. After receiving the data, it can perform coordinate conversion based on that projection type using an appropriate library.

[kminoda]

FYI, here's a draft PR for the above proposal:

• feat(gnss_poser): Subscribe map_projector_info autoware.universe#3984
• feat(map_projection_loader): add map_projection_loader autoware.universe#3986

[kminoda]

autowarefoundation/autoware_common#191

[ataparlar]

Hi. Excellent work here. I understanded the idea and liked the projection choices. I appriciate it.
Just to confirm, this is written for automatic changing of the projection type while vehicle moving, right?
And also I am curious about this: Does the position error increases that much effects the driving while vehicle is near to the MGRS grid boundaries?
Thank you for your works.

[kminoda]

Thanks for the comment!

Just to confirm, this is written for automatic changing of the projection type while vehicle moving, right?

No, we do not intend to change projection type while vehicle moving. For the time being, Autoware will load static projection type defined in e.g. YAML file, and load the map files accordingly. Ideally speaking, Autoware should be able to operate large areas regardless of UTM or MGRS grids or even projection type, e.g. by dynamically changing the projection type while moving. After thorough internal dicussion at TIER IV, however, we came to a conclusion that it is extremely difficult to support such functionality with current Autoware architecture.
(We are happy to discuss in detail somewhere if you want. Indeed we are still open to any ideas for realizing this 👍)

Does the position error increases that much effects the driving while vehicle is near to the MGRS grid boundaries?

I believe that MGRS grid boundaries won't be a problem, since it is just a translational shift between two MGRS grids, as long as they are in same UTM zone. The projection between two coordinates get very complicated when comparing two MGRS (or any arbitrary) coordinates which are located in two different UTM zones, since the transform between them are non-linear projection.

[armaganarsln]

@kminoda are there any updates on the discussions? could you share the results at the mapping WG next time?

[kminoda]

Sorry for not answering the question. I will briefly introduce the results as well as the map interface changes on today's WG. Thanks!

[kminoda]

The proposal has been merged to Autoware. Thank you for all of your discussions.