Feature: Remove Autoware limitations about map boundaries

[ataparlar]

Checklist

• [X] I've read the contribution guidelines.
• [X] I've searched other issues and no duplicate issues were found.
• [X] I've agreed with the maintainers that I can plan this task.

Description

Provide a Dynamic Lanelet2 map loader. (Problem detail below)

Autoware Projections

Autoware has a limitation for map boundaries. Map Projection Loader modules can work for MGRS, Local Cartesian UTM and Transverse Mercator projections. MGRS Projection works inside of the 100km x 100km MGRS grids. Local Cartesian UTM works inside of a UTM zone. Transverse Mercator does not have a limitation. Problems are detected via a lanelet2 map generated via Python script that uses CommonRoad API between Istanbul and Ankara in Turkey. The road lenght is approximately 600km.

Problems with Available Projections

MGRS

The 100km x 100km MGRS grid visualization can be found below. The road overlays more than 1 MGRS grid and the nodes and line segments reaches out the other MGRS grids than the main one keep being inside in the main MGRS grid. So, the 600km road is stuck inside of the main MGRS grid. It seems like the line segments are bouncing from the edges of the main grid. The image related to that problem can be found below.

LocalCartesianUTM

Same situation is valid for Local Cartesian UTM projection. Only difference is the map boundaries. Map boundaries here is not 100km x 100km MG RS grids, they are the UTM zone grids. So, this projection involves much area than MGRS projection but still it is insufficient for long routes. UTM projection visualization on the same road and the same error can be seen below.

TransverseMercator

Transverse Mercator projection hasn't any boundary limitations. Additionally, we are able to load all the roads into the Autoware and visualize it in RViz2 with Planning Simulator or Logging Simulator. However, when we get away from the origin of the lanelet2 map, the line segments, TF markers, 2D Pose Estimate or 2D Goal Pose arrows start to corrupt because of the large numbers. This very looks like a floating point error. RViz2 screenshot can be seen in below GIF. Another issue with Transverse Mercator is corruptions in the map while getting away from the origin. In far places, the map loses its correctness due to the projection surface.

Additionally, due to the large numbers of coordinates and 123 MB lanelet2(.osm) file makes the system very heavy. While this GIF is recording, nearly 20 GBs of RAM is used from the computer by Autoware Planning Simulator.

Purpose

Autoware needs to be compatible with long range drivable lanelet2 maps. While doing that, RAM usage must be kept low.

Possible approaches

Dynamic Lanelet2 Map Loading

Autoware can load point cloud maps dynamicly. This provides better physical component usage for PCs and accelerates the whole Autoware due to the light system. Same situation is valid for Lanelet2 Maps. Error determination tests are implemented with 600 km road overlays different projection zones. Observed that, only Transverse Mercator project is available to use all the map at once but it has floating point problem and loses correctness while getting away from the origin.

MGRS and LocalCartesianUTM works in a boundary and they preserves their sufficient accuracy in the boundary. So, for keep getting sufficient accuracy from the map and for keeping the map outsourcing lower, Lanalet2 Maps can loaded dynamicly as the car moves. As a matter of fact, 10 or 5 km MGRS grids can be used for dynamicly loading and this will provide more compatible position data generation with the real world.

Definition of done

• Autoware loads and uses Lanelet2 maps overlays large areas.
• Maps does not uses too much source from the computer.
• Observing no corruption while getting away from the origin.

[VRichardJP]

Looks very complicated. Just a random idea:

• split the lanelet map into N lanelet maps (~MGRS size), each with its own local projection (referred by frame "mapXX").
• "local" lanelets maps should overlap to have smooth transition from one to the next (similar to dynamic PCD loading).
• A global server tracks vehicle pose and broadcast the current "mapXX" frame to use. Since all frames are fixed and known on startup, it is not a problem if some nodes use different map frame during transition phases (as long as they carefully check and transform each data).
• Obviously, it means all node currently using hardcoded "map" frame must be updated.
• A new global planner must be implemented as the global path from start to goal cannot be known anymore. For this, we could preprocess each "local" lanelet map into a graph saying which lanelet id at the edge of the "local" map can reach which other lanelet id at the edge. The actual local path would only be computed once the vehicle reach the local map.

[ataparlar]

Dynamic Lanelet2 Map Loading

This concept is found necessary for using Autoware in large areas. The main idea is changing the loaded map area while the body is moving. To do that, MGRS grids can be used. Because MGRS grids enables to use the squares of 100km, 10km and 1km areas. We think that 1km MGRS grids will be ok to use. In that way, planning modules can work easily and all the pipeline would use lower amount time towards to larger areas. Here is a demonstration of the idea with a GIF below.

Editing Planning Pipeline According to Map Loading

With dynamicly loaded Lanelet2 maps, a problem is occuring. In large areas, we are not able to give a goal point with this planning implementation. Because the lanelet of the goal point could not be known with dynamicly loaded small Lanelet2 maps.

This situation can be solved with the suggestion made by @VRichardJP, which is using a graph structure to calculate the route with a full Lanelet2 map. This can work I think but this means one or several new package with various new nodes needed to be written and tested. This will cost too much time and too much energy to implement in my opinion. Additionally, I cannot guess the computational cost and how would be the performance in this stage. Still this can be the solution. Thank you for your sharings @VRichardJP.

Another solution can be using a different global planner with implementing it in the Autoware planning pipeline. This solution makes similar approximations with @xmfcx 's thoughts in another discussion about planning performence in large areas from @StepTurtle. We planned to use a global planner for large areas before giving a goal point. In this way, we can know which roads will be used in the route. Additionally, we got a planned route as a linestring and we can use it with planning pipeline.

The main idea here is taking the global planned route and giving goal points in each 1.5 or 2 kilometers to planning pipeline (Goal point can change according to the grid size will be used in Dynamic Lanelet2 Map Loading). Planning works fine in small environments has overall 1 kilometer radius. In that point of view, if we use goal points in a limited length and dynamicly changes the goal points along the globally planned route, it should work. Here is a demonstration of the general plan below.

Due to the complexity of the issue, we would like to discuss this before implement anything. Any comment or ideas would be great. @xmfcx @mitsudome-r

[ataparlar]

@xmfcx @mitsudome-r We can use this issue for only Dynamic Lanelet2 Map Loading and open another issue for route planning if needed. Also those already exist for route planning for large areas:

• 5940

• Investigation on using Large Scale Lanelet2 Map in Autoware | Planning Simulator #4075

[ataparlar]

Using an external planner is not planned right now. The main aim is using mission_planner for large areas too. mission_planner can plan a route even in very long routes as can be seen in this video.

The main goal right now, using mission_planner with Dynamic Lanelet2 Loading. We are aiming it to use in MGRS projection for reaching the lowest projection corruption. However, MGRS projection has a limitation in a 100km x 100km MGRS grid. Besides that being a limitation, it can be an opportunity to use it on our good.

In large areas (over 100km routes), we are aiming to use mission_planner to plan the route. Once it plans the route, we can hold the lanelet ids inside of the route. The only issue here is to keeping coordinates low for not getting floating point errors. We thought that MGRS limitations can help with this. Here is a demonstration of what is planned.

As can be seen in the demonstration, in large areas, we change MGRS grids. In that situation, we will see that the lanelet2 maps of different MGRS grids will overlay due to the MGRS boundaries. To avoid that situation, we are planning that to use MGRS strings to find which MGRS grid the moving vehicle is in. Additonally, with Dynamic Lanelet2 Loading, it is aimed that to load lanelet2 maps according to MGRS string of moving vehicle.

Additionally, for keeping the coordinates low, we can apply the same method to point cloud maps as NDT input. With an MGRS string specification for each lanelet2 map and each point cloud will be able to solve the localization and mapping problem.

We will test this with a point cloud taken from AWSIM and a lanelet2 map generated via CommonRoad API at the crossing of 2 MGRS grids.

@xmfcx @mitsudome-r

[mitsudome-r]

MGRS grid cannot handle goals that is outside 100km x 100km, but can't we use other projection type for longer distance? (e.g., using TransverseMercator projection)

There could be distortion in the long distance anyways, but the topology of lane connection doesn't depend on the projection error so mission_planner should be able to do the route calculation just fine.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[ataparlar]

This issue is related to the MGRS boundaries. We can use LocalCartesian UTM or Transverse Mercator projections in Autoware. In real-life conditions, there won't be a drive that is too long. So, MGRS boundaries are not a problem right now.

We have opened PRs for Dynamic Lanelet2 Map Loading part. They are waiting for reviews.

• https://github.com/autowarefoundation/autoware.universe/pull/6241
• https://github.com/autowarefoundation/autoware_launch/pull/872
• https://github.com/autowarefoundation/autoware_msgs/pull/81
• https://github.com/autowarefoundation/autoware_common/pull/234
• https://github.com/autowarefoundation/autoware.universe/pull/6393

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.