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:
,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:
. 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