ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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
2 | No.2 Revision |
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
3 | No.3 Revision |
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