Robotics StackExchange | Archived questions

Unconnected nodes: Hector_Slam and Navigation

I try to get the hectorslam (github.com/tu-darmstadt-ros-pkg/hectorslam.git /catkin) package running with the navigation stack (github.com/ros-planning/navigation.git /kinetic-devel). The hectorslam package runs well. A map is generated, localization works smooth. Trying to get the hectorslam 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

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

3) The costmapcommonparams.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 globalcostmapparams.yaml

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

5) The localcostmapparams.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?

Asked by FLYINGKNIGHT on 2017-05-21 06:58:06 UTC

Comments

Please add details what the "troubles" are

Asked by Humpelstilzchen on 2017-05-21 08:30:41 UTC

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.

Asked by FLYINGKNIGHT on 2017-05-21 12:47:38 UTC

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?

Asked by Humpelstilzchen on 2017-05-21 13:42:40 UTC

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.

Asked by FLYINGKNIGHT on 2017-05-25 15:02:49 UTC

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.

Asked by Humpelstilzchen on 2017-05-26 02:29:24 UTC

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?

Asked by FLYINGKNIGHT on 2017-05-28 05:11:34 UTC

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.

Asked by FLYINGKNIGHT on 2017-05-28 06:42:39 UTC

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.

Asked by Humpelstilzchen on 2017-05-28 12:23:37 UTC

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/Tutorials/SettingUpForYourRobot#Use_in_place_of_gmapping

Asked by FLYINGKNIGHT on 2017-05-29 13:45:46 UTC

Answers