Navigation stack with hector mapping Issues - Lots of detail provided

asked 2017-10-27 13:10:54 -0500

Ricky-the-Robot gravatar image

updated 2017-10-28 18:33:04 -0500

jayess gravatar image

Hi all,

I am currently trying to implement the navigation stack on a tank-steer robot (similar to differential drive but with 2 wheels on each side) and although the robot is able to navigate to navigation goals in fairly open areas, it seems to get "confused" by navigation goals around walls. All seems well at first and the robot begins to travel in the general direction of the path but then it begins to rotate in place. I am assuming that this is a recovery behavior but, even if a new goal is sent to the robot, it is unable to travel to the new goal. I have been playing with the parameters for several days now and I am still unable to fix this issue, or even isolate why it is happening!

It seems that when the robot gets "confused," the local_planer stops functioning properly (no path is generated) however, the global-planer seems to be working just fine.

Details: I am using rplidar with hector mapping to produce a 2D map and give me my odometry. The topic that hector mapping uses to publish odometry only publishes the position and not the velocity of the robot (the velocity field in the odom msg is always 0 for all directions/rotations). I personally do not think this is the issue as the robot is still able to navigate to goals in open spaces.

I do notice error messages appear when running move_base (need to run robot the get exact errors):

  • Extrapolation Error: Lookup would require extrapolation into the future. Requested time 1509126598.543527562 but the latest data is at time 1509126598.531893800 , when looking up transform from frame [scan_odom] to frame [map]

    ** I think this is caused by the scan_odom tf frame (generated by hector mapping) not being future dated like AMCL does but I thought this problem was supposed to be fixed when the tf.waitfortransform() was added to the navigation stack code back in 2014

  • Global Frame: scan_odom Plan Frame size XX: map

** The number XX varies from 19 to 45 (in one test run)

I do also notice warn messages appear when running move_base:

  • Could not transform the global plan to the frame of the controller

**I have no clue and to what is causing this warn messages.

Here are my launch and yaml files for the move_base/navigation stack:

move_base.launch:

<launch>
  <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
    <!-- Added to remove Error regarding expected 20Hz -->
    <param name="controller_frequency" value="5.0" />
    <rosparam file="$(find motor_api)/costmap_common_params.yaml" command="load" ns="global_costmap" />
    <rosparam file="$(find motor_api)/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find motor_api)/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find motor_api)/global_costmap_params.yaml" command="load" />
    <rosparam file="$(find motor_api)/base_local_planner_params.yaml" command="load" />
  </node>
</launch>

costmap_common_params.yaml:

footprint: [[0.32, 0.31], [-0.32, 0.31], [-0.32, -0.31], [0.32, -0.31]]
transform_tolerance: 0.4
obstacle_range: 1.5
raytrace_range: 2.0
inflation_radius: 0.157 #6 Inches
observation_sources ...
(more)
edit retag flag offensive close merge delete

Comments

Welcome! To use the syntax highlighting feature please don't use HTML elements or <code> tags. Simply insert your text, highlight it with your mouse, then click the Preformatted Text (101010) button.

jayess gravatar imagejayess ( 2017-10-28 18:35:42 -0500 )edit

Thank you for editing the post! I will keep that in mind for future reference.

Ricky-the-Robot gravatar imageRicky-the-Robot ( 2017-10-30 13:21:24 -0500 )edit