navigation with rviz won't move robot with 2D pose estimate using zed2
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 pointcloudtolaserscan 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 --->
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--->
move_base.launch:
<launch>
<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" />
</node>
</launch>
baselocalplanner_params.yaml:
TrajectoryPlannerROS:
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
costmancommonparams.yaml:
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}
globalcostmapparams.yaml:
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 5.0
static_map: true
localcostmapparams.yaml:
local_costmap:
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
Asked by ROSNewbie on 2022-02-17 14:28:24 UTC
Answers
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:
https://answers.ros.org/question/223880/what-is-rolling-window-used-for/ https://answers.ros.org/question/9845/move_base-warning-sensor-out-of-bounds/
Asked by osilva on 2022-02-18 07:45:02 UTC
Comments
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.
Asked by ROSNewbie on 2022-02-18 11:41:14 UTC
I solved this by running
roswtf
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
.
Asked by ROSNewbie on 2022-02-21 13:57:49 UTC
Comments