ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Your second approach seems to be the better one. move_base (or more precisely the navigation_stack) utilizes costmap_2d for its planning "computation", and it uses the robot's base frame as the current pose of the robot. Fortunately you can change that by setting the robot_base_frame parameter of both the global and local costmap configuration, or by simply include it in the common configuration. See here for more detail : http://wiki.ros.org/navigation/Tutorials/RobotSetup#Costmap_Configuration_.28local_costmap.29_.26_.28global_costmap.29

Your second approach seems to be the better one. move_base (or more precisely the navigation_stack) utilizes costmap_2d for its planning "computation", and it uses the robot's base frame as the current pose of the robot. Fortunately you can change adjust that by setting the robot_base_frame parameter of both the global and local costmap configuration, or by simply include it in the common configuration. See here for more detail : http://wiki.ros.org/navigation/Tutorials/RobotSetup#Costmap_Configuration_.28local_costmap.29_.26_.28global_costmap.29

Your second approach seems to be the better one. move_base (or more precisely the navigation_stack) utilizes costmap_2d for its planning "computation", and it uses the robot's base frame as the current pose of the robot. Fortunately you can adjust that by setting the robot_base_frame parameter of both the global and local costmap configuration, or by simply include it in the common configuration. configuration. Just set robot_base_frame to your odom_future and that should be it.

See here for more detail : http://wiki.ros.org/navigation/Tutorials/RobotSetup#Costmap_Configuration_.28local_costmap.29_.26_.28global_costmap.29