Loading georeferenced maps

[enesadastec]

Hi,

We can not visualize georefenced maps on rviz directly. To visualize georeferenced maps on rviz, first we need to import our map file to CloudCompare and convert to local coordinates by using global shifting feature of CloudCompare. After saving new map file, we can visualize in rviz.

Rather than doing this steps manually, is it possible to add this feature to map_loader?

[mitsudome-r]

If you are using default autoware.launch.xml, it should be launching map_tf_generator which publishes "viewer" tf frame at the centroid of the loaded map for visualization. By default, it is launching VectorMapTFGeneratorNode which uses lanelet2 map to generate the tf, but you can change it to PcdMapTFGeneratorNode if you want to generate the tf from point cloud map.
https://github.com/autowarefoundation/autoware.universe/blob/1469f52c1a738e6512437317e2588561bc024c60/launch/tier4_map_launch/launch/map.launch.py#L99

Then, you can specify "viewer" frame in RVIZ to visualize the map.

[enesadastec]

As i mentioned on the meeting, this method is not working for georeferenced maps which has coordinates like 4.000.000. Because "map_tf_generator" package is reading .pcd files as pcl::PointXYZ which is float and not supports bigger coordinates.

Here is coordinates of my georeferenced maps:

Also we can not visualize georeferenced maps on RVIZ, because also RVIZ supports float points only

My suggested solution is that;
We should add an option to map_loader/pointcloud_map_loader to get origin of the map points and substract them from other coordinates to convert georeferenced maps to local maps before visualizing them.
https://github.com/autowarefoundation/autoware.universe/blob/1469f52c1a738e6512437317e2588561bc024c60/map/map_loader/config/lanelet2_map_loader.param.yaml#L1

While doing that, we might need to define our own custom pcl point type which has double type to read bigger coordinates like here;

[mitsudome-r]

@enesadastec
Do you think it makes sense to convert the coordinates beforehand rather than subtracting at load time?
In order do match with Lanelet2 map coordinates, the user should be aware of what coordinates they should be using for the origin anyways.

I think defining a custom PCL point type is a good idea, but we would also have to create our own implementations for some of PCL library functions in that case since some only supports float point types.

[enesadastec]

I think every way that converts georeferenced coordinates to local coordinates are makes sense. We can think about how we can convert to local coordinates beforehand rather than load time. Im not sure it will match with lanelet2 coordinates if we convert to local coordinates.

Rather than editing all PCL implementations, maybe we can create a node that converts georeferenced map to local coordinates and publishes. With this way, without editing the other nodes we can use local map on another nodes as usual.

[meliketanrikulu]

Rather than doing this steps manually, is it possible to add this feature to map_loader?

What is your projection type here. Are you using UTM or MGRS. We are using MGRS. Its includes global coordinates and there is no problem there.

[enesadastec]

Rather than doing this steps manually, is it possible to add this feature to map_loader?

What is your projection type here. Are you using UTM or MGRS. We are using MGRS. Its includes global coordinates and there is no problem there.

I was trying to load UTM coordinates to RVIZ. Because of the data structure (float32) of the RVIZ, some UTM maps can not visualized on RVIZ and CloudCompare's global shifting feature is solution for that problem.

[kminoda]

This may be an overlapping question, but why not using MGRS? As long as the operating area is within MGRS (10km x 10km at maximum), it should work fine without changing the map loader. Most of the map in TIER IV is indeed handled in MGRS grid coordinate, and it is working fine.

Is it because you don't want to subtract the coordinate beforehand?