Unconnected nodes: Hector_Slam and Navigation

asked 2017-05-21 06:58:06 -0600

FLYINGKNIGHT gravatar image

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: rosgraph

The tf view_frames delivers: tf_frames

My configuration files for the navigation stack are as the following ones:

1) The "top level" configuration file

  <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" />

2) The base_local_planner_params.yaml:

  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_frame: map
  robot_base_frame: base_link
# update_frequency: 5.0
  static_map: true

5) The local_costmap_params.yaml

  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?

edit retag flag offensive close merge delete


Please add details what the "troubles" are

Humpelstilzchen gravatar image Humpelstilzchen  ( 2017-05-21 08:30:41 -0600 )edit

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.

FLYINGKNIGHT gravatar image FLYINGKNIGHT  ( 2017-05-21 12:47:38 -0600 )edit

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?

Humpelstilzchen gravatar image Humpelstilzchen  ( 2017-05-21 13:42:40 -0600 )edit

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.

FLYINGKNIGHT gravatar image FLYINGKNIGHT  ( 2017-05-25 15:02:49 -0600 )edit

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.

Humpelstilzchen gravatar image Humpelstilzchen  ( 2017-05-26 02:29:24 -0600 )edit

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?

FLYINGKNIGHT gravatar image FLYINGKNIGHT  ( 2017-05-28 05:11:34 -0600 )edit

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.

FLYINGKNIGHT gravatar image FLYINGKNIGHT  ( 2017-05-28 06:42:39 -0600 )edit

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.

Humpelstilzchen gravatar image Humpelstilzchen  ( 2017-05-28 12:23:37 -0600 )edit