Robotics StackExchange | Archived questions

Local planner is not able to reach a goal in free space

Hi,

I'm having some problems in tuning up the local planner for a custom skid-steer wheeled robot to be able to navigate to waypoints in free space. I'm using the gazebo skidsteerdrive_controller to simulate it. I still don't understand why the local planner is not turning in place in order to reach the desired goal orientation instead of moving forward and turn to reach it. This is the video of what is happening:

video

,as you can see in the video, the robot is not able to reach the goal. Similar robots, like Husky, are able to reach goals by turning in place. For example, this video:

video2

. In fact, I'm using the same configuration params for the common, local and global costmap and the local planner as in the simulated Husky in the video. For reference, I'm posting these configuration params.

By the way, this is a similar question but I'm my case, I'm not dealing with obstacles at the moment:

https://answers.ros.org/question/215758/how-do-i-make-the-local-planner-rotate-in-place/

Please let me know any other information that could be useful.

costmapcommonparams.yaml

map_type: costmap
origin_z: 0.0
z_resolution: 1 # The z resolution of the map in meters/cell.
z_voxels: 2  # The number of voxels to in each vertical column, the height of the grid is z resolution * z voxels.

obstacle_range: 2.5
raytrace_range: 5.5

publish_voxel_map: false

footprint: [ [0.23, 0.23], [0.23, -0.23], [-0.23, -0.23], [-0.23, 0.23] ]
inflation_radius: 0.35
cost_scaling_factor: 1 # slope of the cost decay curve with respect to distance from the object. lower makes robot stay further from obstacles

# transform_tolerance: 5

robot_radius: 0.25
footprint_padding: 0.2

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: hokuyo, data_type: LaserScan, topic: /skid_steer_bot/laser/scan, marking: true, clearing: true}

globalcostmapparams.yaml

global_costmap:
  global_frame: odom
  robot_base_frame: robot_footprint
  update_frequency: 20.0
  publish_frequency: 5.0
  width: 30.0
  height: 30.0
  # resolution: 0.05
  rolling_window: true
  static_map: false  
  track_unknown_space: true
  # plugins:
  #   - {name: obstacles_laser,           type: "costmap_2d::ObstacleLayer"}
  #   - {name: inflation,                 type: "costmap_2d::InflationLayer"}

localcostmapparams.yaml

local_costmap:
  global_frame: odom
  robot_base_frame: robot_footprint
  update_frequency: 1.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 10.0
  height: 10.0
  resolution: 0.05

baselocalplanner_params.yaml

TrajectoryPlannerROS:
  max_vel_x: 0.6
  # min_vel_x: 0.15
  min_vel_x: 0.15 # Allowing velocities too low will will stop the obstacle avoidance because low velocities won't actually be high enough to move the robot
  max_vel_theta: 1.0
  min_vel_theta: -1.0
  min_in_place_vel_theta: 0.4

  acc_lim_theta: 1.0
  acc_lim_x: 1.0
  acc_lim_y: 0.0

  holonomic_robot: false

  # New Stuff

  escape_vel: -0.2

  # Goal Tolerance Parameters
  yaw_goal_tolerance: 0.1  # in rads
  xy_goal_tolerance: 0.2  # in meters
  latch_xy_goal_tolerance: false

  # Forward Simulation Parameters
    # these parameters change how the planner simulates trajectories at each update and therefore changes the optimal trajectory that is chosen
    # These should be adjusted based on your computer performance
  sim_time: 2.0   # setting time of each simulation that it must evaluate. Higher will create longer curves but too low can limit performance (<2)
  sim_granularity: 0.02 # the step size to take between points on a trajectory, or how frequent should the points on this trajectory should be examined
  angular_sim_granularity: 0.02
  vx_samples: 10  # how many samples of x velocity are taken for simulated trajectories
  vtheta_samples: 30 # how many samples of theta velocity are taken for simulated trajectories
  controller_frequency: 1.0  # how often the planning algorithm is performed (hz)

  # Trajectory scoring parameters
  meter_scoring: true # Whether the gdist_scale and pdist_scale parameters should assume that goal_distance and path_distance are expressed in units of meters or cells. Cells are assumed by default (false).
  occdist_scale:  0.1 #The weighting for how much the controller should attempt to avoid obstacles. default 0.01
  pdist_scale: 0.5  #     The weighting for how much the controller should stay close to the path it was given . default 0.6
  gdist_scale: 1.0 #     The weighting for how much the controller should attempt to reach its local goal, also controls speed  default 0.8

  heading_lookahead: 0.325  #How far to look ahead in meters when scoring different in-place-rotation trajectories
  heading_scoring: false  #Whether to score based on the robot's heading to the path or its distance from the path. default false
  heading_scoring_timestep: 0.8   #How far to look ahead in time in seconds along the simulated trajectory when using heading scoring (double, default: 0.8)
  dwa: true #Whether to use the Dynamic Window Approach (DWA)_ or whether to use Trajectory Rollout
  simple_attractor: false
  publish_cost_grid_pc: true  

  # Oscillation Prevention Parameters
  oscillation_reset_dist: 0.25 #How far the robot must travel in meters before oscillation flags are reset (double, default: 0.05)
  escape_reset_dist: 0.1
  escape_reset_theta: 0.1

Asked by andrestoga on 2019-07-22 22:06:33 UTC

Comments

im not sure how different is your custom skid-steer wheeled robot from the husky. As I can see from the video maybe you can try increasing the angular velocities and angular acceleration. This will force the robot to start turning earlier.

Asked by pavel92 on 2019-07-24 06:12:17 UTC

Answers