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.