Unconnected nodes: Hector_Slam and Navigation
I try to get the hector_slam (github.com/tu-darmstadt-ros-pkg/hector_slam.git /catkin) package running with the navigation stack (github.com/ros-planning/navigation.git /kinetic-devel). The hector_slam package runs well. A map is generated, localization works smooth. Trying to get the hector_slam running with the navigation stack leads me to troubles.
I think that I'm doing something wrong with the configuration.
roswtf tells me:
Found 1 warning(s).
Warnings are things that may be just fine, but are sometimes at fault
WARNING The following node subscriptions are unconnected:
* /hector_mapping:
* /initialpose
* /syscommand
* /tf_static
* /move_base:
* /move_base_simple/goal
* /tf_static
* /odom
* /move_base/cancel
Found 1 error(s).
ERROR The following nodes should be connected but aren't:
* /move_base->/move_base (/move_base/global_costmap/footprint)
* /move_base->/move_base (/move_base/local_costmap/footprint)
The rosgraph looks like this:
The tf view_frames delivers:
My configuration files for the navigation stack are as the following ones:
1) The "top level" configuration file
<launch>
<include file="$(find rplidar_ros)/launch/rplidar.launch" />
<include file="$(find hector_slam_launch)/launch/slam.launch" />
<!-- <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 darkmole_nav)/costmap_common_params.yaml" command="load" ns="global_costmap" />
<rosparam file="$(find darkmole_nav)/costmap_common_params.yaml" command="load" ns="local_costmap" />
<rosparam file="$(find darkmole_nav)/local_costmap_params.yaml" command="load" />
<rosparam file="$(find darkmole_nav)/global_costmap_params.yaml" command="load" />
<rosparam file="$(find darkmole_nav)/base_local_planner_params.yaml" command="load" />
</node>
</launch>
2) The base_local_planner_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
3) The costmap_common_params.yaml
obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[0.305, 0.278], [0.04, 0.193], [-0.04, 0.193], [-0.282, 0.178], [-0.282, -0.178], [-0.04, -0.193], [0.04, -0.193], [0.305, -0.278]]
#robot_radius: ir_of_robot
inflation_radius: 0.55
transform_tolerance: 1.5
observation_sources: laser_scan_sensor
update_frequency: 1.0
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
4) The global_costmap_params.yaml
global_costmap:
global_frame: map
robot_base_frame: base_link
# update_frequency: 5.0
static_map: true
5) The local_costmap_params.yaml
local_costmap:
global_frame: map
robot_base_frame: base_link
# update_frequency: 5.0
publish_frequency: 2.0
static_map: true
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.05
What did I wrong here?
Please add details what the "troubles" are
Hi Humpelstilzchen,
thank you for your comment.
1) Sending goals is okay. But a navigation path is not calculated. 2) While looking for the problem myself I "activated" roswtf. It said me that there are unconnected nodes. See the beginning of my question.
Usually move_base outputs a lot of logging information when something is wrong. From the roswtf output: Yes, odom unconnected is usually a major problem. Doesn't your robot have odometry output?
Hi again, I am sorry for the delayed answer.
My robot provides odom published by the hector_slam. After your hint I took a look into the rosgraph. The topic 'scanmatch_odom' seems unconnected. I also do not see any chance to configure it somewhere in the navigation stack.
ok, so no real odom, you could remap the scanmatch_odom. But using hector_mapping this is probably not what you want. Also I don't see odom used in your config. But I don't know hector_slam_launch)/launch/slam.launch. It doesn't seem to exist.
I think you're probably right. hector_mapping delivers 'scanmatch_odom' topic, the navigation stack consumes 'odom' topic. Remapping could solve the problem. Why do you say, that hector_mapping is probably not what I want? Is there another (improved) way to go?
When remapping the topic to '/odom' the navigation stack tells that 'odom' is found. That's great. But when I'm sending 2D Nav Goals (via Rviz) there is no (global /local) plan calculated and showed in Rviz.
A remap is probably not what you want since hector is afaik optimized to work without odometry information (Correct me?). The odometry publisher of hector doesn't even seem to be documented.
You're right. Hector is built to work without consuming odometry. But it is able to produce odometry data. It is not described very well. The information is a little bit hidden, see http://wiki.ros.org/hector_slam/Tutor...