Frame Id Clarification for Raw and Fused Elevation Maps

[sarahnator]

Hi, I was hoping to get some input on the frame ids of the maps in this package. I had a few questions:

• For the parameter map_frame_id, I noticed that some demos used "map" for this value, whereas other demos used "odom." In the case where we do not have a ground truth localization system, these values mean different things. For operating in a robot-centric local frame, I assume we would want to use the "odom" frame (like how the global_frame is odom in the local_costmap configuration of the ROS navigation stack)?

• Second, both the raw and fused maps are published with the frame_id parameter map_frame_id. Does this mean that the maps are both robot-centric and identical with the exception that the fused map uses a representation that requires more computation and is therefore published less frequently?

Thank you!

[maximilianwulf]

For the parameter map_frame_id, I noticed that some demos used "map" for this value, whereas other demos used "odom." In the case where we do not have a ground truth localization system, these values mean different things. For operating in a robot-centric local frame, I assume we would want to use the "odom" frame (like how the global_frame is odom in the local_costmap configuration of the ROS navigation stack)?

map and odom can be used interchangeably.

Second, both the raw and fused maps are published with the frame_id parameter map_frame_id. Does this mean that the maps are both robot-centric and identical with the exception that the fused map uses a representation that requires more computation and is therefore published less frequently?

Yes, the fused map does some probabilistic computations on the raw map. The process is slow compared to the raw mapping.