rst-tu-dortmund / teb_local_planner

An optimal trajectory planner considering distinctive topologies for mobile robots based on Timed-Elastic-Bands (ROS Package)
http://wiki.ros.org/teb_local_planner
BSD 3-Clause "New" or "Revised" License
1.03k stars 546 forks source link

Rotating inplace #157

Open abylikhsanov opened 5 years ago

abylikhsanov commented 5 years ago

I am using teb_local_planner for the differential robot and besides of the regular oscillations during the movement, when I post a goal which is at the back of the robot (180 degrees), robot cannot follow the plan anymore, what could it be?

Here is my config file and I also post the video below

TebLocalPlannerROS:

 odom_topic: odom
 map_frame: /map

 # 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.4
 max_vel_x_backwards: 0.2
 max_vel_theta: 0.3
 acc_lim_x: 0.1
 acc_lim_theta: 0.2
 min_turning_radius: 0.0
 footprint_model: # types: "point", "circular", "two_circles", "line", "polygon"
   type: "point"
   radius: 0.2 # for type "circular"
   line_start: [-0.3, 0.0] # for type "line"
   line_end: [0.3, 0.0] # for type "line"
   front_offset: 0.2 # for type "two_circles"
   front_radius: 0.2 # for type "two_circles"
   rear_offset: 0.2 # for type "two_circles"
   rear_radius: 0.2 # for type "two_circles"
   vertices: [ [0.25, -0.05], [0.18, -0.05], [0.18, -0.18], [-0.19, -0.18], [-0.25, 0], [-0.19, 0.18], [0.18, 0.18], [0.18, 0.05], [0.25, 0.05] ] # for type "polygon"

 # GoalTolerance

 xy_goal_tolerance: 0.2
 yaw_goal_tolerance: 0.1
 free_goal_vel: False

 # Obstacles

 min_obstacle_dist: 0.4
 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
 weight_dynamic_obstacle: 10 # not in use yet
 alternative_time_cost: False # not in use yet

 # Homotopy Class Planner

 enable_homotopy_class_planning: True
 enable_multithreading: True
 simple_exploration: False
 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

Video: https://drive.google.com/file/d/1qYd8-VuSO7P1yGoRVrdAhhwDhX4qaN1S/view?usp=sharing

simonbogh commented 5 years ago

Sounds like the same problem as here: https://answers.ros.org/question/172051/base_scan-observation-buffer-has-not-been-updated/

Could you please check that topic and sensor_frame are correct in your costmap_common_params.yaml under observation_sources?

It could also be latency in the system. In the same file you could also, for testing, try to increase expected_update_rate: 0.2. If the sensor data is outdated then move_base will not send anything to cmd_vel.

Here is the configuration for my robot. Topic and sensor_frame may be different for your robot.

laser_scanner: {topic: /laser_unified/scan,
                sensor_frame: /scan_combined,
                expected_update_rate: 1.0,
                data_type: LaserScan,                                             
                clearing: true,              
                marking: true,               
                }