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 skid_steer_drive_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/2157...
Please let me know any other information that could be useful.
costmap_common_params.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}
global_costmap_params.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"}
local_costmap_params.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
base_local_planner_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 ...
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.