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

navigation with rviz won't move robot with 2D pose estimate using zed2

asked 2022-02-17 13:28:24 -0500

ROSNewbie gravatar image

updated 2022-02-17 13:37:57 -0500

Good day, I am attempting the basic navigation example here.

I am trying to learn how to use the navigation stack so accuracy is of no importance right now.

The difference between the example and my setup is that I am only proving a /scan message to the amcl from the zed2 stereo camera, no pointcloud data (by running a pointcloud_to_laserscan node to convert the PointCloud data to laserscan). I also provided a static map using a map server.

I did not set up any tf myself because I saw that the zed's ROS code would handle all this and when I check the tree in rqt it seems to match with the example. (for now I don't mind if the camera's center and robot's center is the same as I would just like to get this up and running)

See my tf tree --->rqt graph of tf tree

What I would like to do I get the robot to navigate around the static map I've provided.

The problem occurs when I open rviz and try to change the initialpose of my robot using the 2D Pose Estimate button. The tf tree for odom changes location but the robot does not move. Its base link remains in the original position but for a split second it can be seen jumping to a random location then back to the original position.

Here is the terminal output warning I get from rviz:

[ WARN] [1645126549.371862224]: The origin for the sensor at (-0.04, 0.31) is out of map bounds. So, the costmap cannot raytrace for it.

Additional information and code:

ROS version: melodic

system: Ubuntu 18.04

rosnode graph---> image description



   <master auto="start"/>
 <!-- Run the map server --> 
    <node name="map_server" pkg="map_server" type="map_server" args="$(find sentry_map_provider)/willow-2010-02-18-0.10.pgm 0.100000"/>

 <!--- Run AMCL --> 
    <include file="$(find amcl)/examples/amcl_diff.launch" />

   <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
    <rosparam file="$(find sentry_2dnav)/costmap_common_params.yaml" command="load" ns="global_costmap" /> 
    <rosparam file="$(find sentry_2dnav)/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find sentry_2dnav)/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find sentry_2dnav)/global_costmap_params.yaml" command="load" /> 
    <rosparam file="$(find sentry_2dnav)/base_local_planner_params.yaml" command="load" />



  max_vel_x: 0.45
  min_vel_x: 0.1
  max_vel_theta: 1.0
  min_in_place_vel_theta: 0.4

  acc_lim_theta: 3.2
  acc_lim_x: 2.5
  acc_lim_y: 2.5

  holonomic_robot: false


obstacle_range: 0.5
raytrace_range: 3.0

footprint: [[-0.25,-0.5],[-0.25,0.5],[0.25,0.5],[0.25,-0.5]]

inflation_radius: 0.55

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: zed2_base_link, data_type: LaserScan, topic: /scan, marking: true, clearing: true}


  global_frame: map
  robot_base_frame: base_link
  update_frequency: 5.0
  static_map: true


      global_frame: odom
      robot_base_frame: base_link
      update_frequency: 5.0
      publish_frequency: 2.0
      static_map: false
      rolling_window: true
      width: 6.0
      height: 6.0
      resolution: 0.05
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2022-02-21 12:57:49 -0500

ROSNewbie gravatar image

I solved this by running


This tool found a contention between the amcl node and the zed ros wrapper. The were both publishing the same transform which explained the jumping back and forth.

At this point in time I have no idea which one should be allowed to publish the tf but I tried to turn off the amcl tf publish tf_broadcast :=false but this showed no difference so I went into the zed_wrapper/params/zed2.yaml file and added under pos_tracking I set publish_map_tf: false.

edit flag offensive delete link more

answered 2022-02-18 06:45:02 -0500

osilva gravatar image

For error:

The origin for the sensor at (-0.04, 0.31) is out of map bounds. So, the costmap cannot raytrace for it.

Try adding to your global_costmap:

rolling_window: true

What is rolling window?

"Rolling window" means that you do not use the costmap to represent your complete environment, but only to represent your local surroundings (e.g. 5m x 5m around your robot). The costmap will then move along with your robot and will be updated by incoming sensor data.

Reference prior answers:

edit flag offensive delete link more


Thank you for the response, however the issue persists and the warning remains. For a fraction of a second I can see the tf for the base_link jumping to where it should be then returning to the origin.

ROSNewbie gravatar image ROSNewbie  ( 2022-02-18 10:41:14 -0500 )edit

Question Tools

1 follower


Asked: 2022-02-17 13:28:24 -0500

Seen: 213 times

Last updated: Feb 21 '22