Which coordinate system should be used for local planning, odom or map?

Question

I am designing a local planning system, and based on the suggestions provided on the ROS Wiki, it seems that the real-time reliability of the odom coordinate system is higher. Therefore, I have chosen odom as the planning coordinate system.

However, this has led me to encounter a problem:

Initially, the odom coordinate system and the map coordinate system overlap. However, as the robot moves, the odom coordinate system can drift due to various reasons. Even though I have set odom as the coordinate system for the local costmap (using the Costmap2D class), the values of the original x and y do not change with the drift of the odom. They seem to remain fixed. This results in a high probability of querying invalid results due to out-of-bounds when I use the local costmap to query map obstacles.

Does this mean that I need to switch from odom to map for querying? Is this an unnecessary step? Or is it possible for my local planner to directly use the map coordinate system?

Thank you, everyone.

---

my costmap configuration is as below

local_costmap:
   global_frame: odom 
   robot_base_frame: base_link
   update_frequency: 10.0  
   
   publish_frequency: 5.0

  #We'll configure this costmap to be a rolling window... meaning it is always
  #centered at the robot

   static_map: false

   rolling_window: true
   width: 5.0  
   height: 5.0 
   resolution: 0.05

   map_type: costmap
   origin_x: 0.0 #5.0
   origin_y: 0.0

   transform_tolerance: 2.0
   track_unknown_space: false

   plugins:
    - {name: voxel_layer,      type: "costmap_2d::VoxelLayer"}
    - {name: inflation_layer,     type: "costmap_2d::InflationLayer"}    
    - {name: obstacles,  type: "costmap_2d::VoxelLayer" }

Answer 1

It's not entirely clear what is going on with your robot, but I see two possible issues:

• When using the costmap_2d package, the local costmap is usually quite small (so that updates can be done quickly) and centered on the robot - it sounds like maybe the second part isn't setup correctly for your use case. Check out the "rolling_window" parameter, and possibly also check your costmap width/height.
• How is your "map"->"odom" transform generated? It should be created by some sort of closed-loop localization (for instance, using the AMCL package). This localization would basically correct for the odometry drift using feedback from a laser scanner to align the robot with the map.