ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

teb_local_planner does not publish to cmd_vel?

asked 2019-02-27 04:47:48 -0600

halberd gravatar image

updated 2019-02-27 05:18:01 -0600

On a robot that makes use of the default navigation stack, I have recently changed the base local planner to TebLocalPlanner to experiment with its performance and results. The paths it draws in rviz are favourable, but the robot is not moving. via rostopic echo I've found that the goals are set and that the planner's returning the steps to take, but cmd_vel remains devoid of activity. I'm unable to determine where the issue lies as I am not given any error either, both via console outputs and roswtf. The nodes in rqt_graph are properly connected as well, so I'm a bit at a loss. The goal's given via rviz's "2D nav goal" button, and base_local_planner adhered to this by also moving the robot (albeit with a lot of oscillation, which is why I'm looking into a different planner to see if it could be minimized in various ways)

In short; after setting up teb_local_planner via the tutorials, rviz shows the calculated paths, but neither the robot nor cmd_vel receive movement commands, no error is provided by the logs and roswtf.

The question; where would the cause be and how would I be able to solve it along with the issues above?

-Edit: Pasted config files directly as requested.-


controller_frequency: 3.0
recovery_behavior_enabled: false
clearing_rotation_allowed: false
recovery_behaviors: [{name: conservative_reset, type: clear_costmap_recovery/ClearCostmapRecovery}, {name: aggressive_reset, type: clear_costmap_recovery/ClearCostmapRecovery}]


  odom_topic: odom
  map_frame: /odom

  # Trajectory
  teb_autosize: True
  dt_ref: 0.3
  dt_hysteresis: 0.1
  global_plan_overwrite_orientation: True
  max_global_plan_lookahead_dist: 3.0
  feasibility_check_no_poses: 5

  # Robot
  max_vel_x: 0.6
  max_vel_x_backwards: 0.2
  max_vel_theta: 0.5
  acc_lim_x: 0.7
  acc_lim_theta: 0.7
  min_turning_radius: 0.2
  footprint_model: # types: "point", "circular", "two_circles", "line", "polygon"
    type: "two_circles" # otherwise line
    front_offset: 0.0 
    front_radius: 0.6 
    rear_offset: 0.5 
    rear_radius: 0.6

 # GoalTolerance
 xy_goal_tolerance: 0.2
 yaw_goal_tolerance: 0.1
 free_goal_vel: False

 # Obstacles
 min_obstacle_dist: 0.2
 include_costmap_obstacles: True
 costmap_obstacles_behind_robot_dist: 1.0
 obstacle_poses_affected: 30
 costmap_converter_plugin: ""
 costmap_converter_spin_thread: True
 costmap_converter_rate: 5

  # Optimization

  no_inner_iterations: 5
  no_outer_iterations: 4
  optimization_activate: True
  optimization_verbose: False
  penalty_epsilon: 0.1
  weight_max_vel_x: 2
  weight_max_vel_theta: 1
  weight_acc_lim_x: 1
  weight_acc_lim_theta: 1
  weight_kinematics_nh: 1000
  weight_kinematics_forward_drive: 1
  weight_kinematics_turning_radius: 1
  weight_optimaltime: 1
  weight_obstacle: 50

  # Homotopy Class Planner

  enable_homotopy_class_planning: False
  enable_multithreading: True
  simple_exploration: True
  max_number_classes: 4
  roadmap_graph_no_samples: 15
  roadmap_graph_area_width: 5
  h_signature_prescaler: 0.5
  h_signature_threshold: 0.1
  obstacle_keypoint_offset: 0.1
  obstacle_heading_threshold: 0.45
  visualize_hc_graph: False


  - {name: static_layer, type: 'costmap_2d::StaticLayer'}
  - {name: obstacle_layer, type: 'costmap_2d::ObstacleLayer'}
  - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
  - {name: sonar,   type: "range_sensor_layer::RangeSensorLayer"}

footprint: [[0.25,-0.31],[0.25,0.31],[-0.69,0.31],[-0.69,-0.31]]
footprint_padding: 0.05

    inflation_radius: 1.75
    cost_scaling_factor: 2.58

    topics: ['/sonar_data']

    combination_method: 1
    enabled: true
    footprint_clearing_enabled: true
    max_obstacle_height: 0.6
    observation_sources: scan
    obstacle_range: 2.0
    raytrace_range: 2.0
    scan: {clearing: true, data_type: LaserScan, expected_update_rate: 0, marking: true,
      topic: /scan_filtered}


   global_frame: odom
   robot_base_frame: base_link
   update_frequency: 3.0
   publish_frequency: 1.0
   static_map: true
   rolling_window: true
   width: 2.0
   height: 2.0
   resolution: 0.05
   transform_tolerance: 1.0
   map_type: costmap

      inflation_radius: 0.2
      cost_scaling_factor: 10
edit retag flag offensive close merge delete


Please include the configuration file contents directly in your question. That way we keep things self-contained as much as possible.

gvdhoorn gravatar image gvdhoorn  ( 2019-02-27 04:52:03 -0600 )edit

Could you also add in the local (and common) costmap parameters? Also, 'the paths it draws in RViz' is the local plan and not the global plan, i assume?

harshal gravatar image harshal  ( 2019-02-27 04:59:48 -0600 )edit

Correct. Although I have both enabled for verbosity, I mainly intend to follow the local plan, which responds well to people moving in front of it.

halberd gravatar image halberd  ( 2019-02-27 05:21:07 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-02-27 06:00:25 -0600

halberd gravatar image

I have discovered the cause; in the launch file for the navigation stack it appeared the cmd_vel topic was being remapped to a different name. As such, the original cmd_vel wouldn't receive the commands from the local plan.

It all seems to work just fine now, with the robot driving a little more straight as a result. Apologies for any inconvenience!

edit flag offensive delete link more

Question Tools



Asked: 2019-02-27 04:47:48 -0600

Seen: 602 times

Last updated: Feb 27 '19