Hi!
I have a setup in which I would like to send the robot to explore narrow corridors (~10-20 cm wider than the robot body).
Here is how it can look like in the simulated environment:
Currently in my setup I'm using:
- dwa_local_planner
- global_planner
the global costmap is inflated quite significantly to produce nice turns, while the local planner is barely inflated so that the robot can go through corridors.
There are two issues I'm coming across:
- Quite often when robot is in the corridor and I ask it to go forward it turns slightly to the right and proceeds turning right resulting in the robot getting stuck between two walls (https://i.imgur.com/9Mzqvnq.mp4)
- The global path leading from one corridor to another is quite often too tight to make a turn (it seems as if the robot begins the turn prematurely) (https://i.imgur.com/SfKkqzb.mp4)
For solving 2 I already increased the cost_factor of global planner which could help a bit (at least looking at the guide it seemed it could help).
Any further pointers on tuning this system would be highly appreciated!
Update 1
I've run quite many tests with the setup, managed to tune most of the troubling behaviour except one! The issue seems to be that if I place the nav goal in the lane adjecent to the one robot is in and the goal is far down the lane the robot gets stuck (https://i.imgur.com/AxwWHWJ.gif)
If the goal is at the beginning of the narrow lane then the robot happily travels to it (https://i.imgur.com/9mtgHpx.gif).
It seems to me that the problem is most probably related to some of the scoring parameters but I was unable to tune it out. Any advice would be highly appreciated!
Below are some of my settings:
DWA:
DWAPlannerROS:
holonomic_robot: false
publish_traj_pc: true
max_vel_x: 1.5
min_vel_x: -0.3
max_vel_y: 0
min_vel_y: 0
max_rot_vel: 3
min_rot_vel: 0.01
acc_lim_x: 6.5
acc_lim_theta: 25
xy_goal_tolerance: 0.1
yaw_goal_tolerance: 0.1
latch_xy_goal_tolerance: true
sim_time: 1.5
sim_granularity: 0.025
forward_point_distance: 0
path_distance_bias: 32
goal_distance_bias: 20
occdist_scale: 0.02
# heading_lookahead: 0.1
# twirling_scale: 0
vx_samples: 20
vy_samples: 0
vth_samples: 40
use_dwa: false
move_base:
shutdown_costmaps: false
max_planning_retries: -1
controller_frequency: 20.0
controller_patience: 15.0
planner_frequency: 0.0
planner_patience: 5.0
max_planning_retries: 5
oscillation_timeout: 5
oscillation_distance: 0.5
# recovery_behavior_enabled: true
# clearing_rotation_allowed: true
# base_local_planner: "teb_local_planner/TebLocalPlannerROS"
base_local_planner: "dwa_local_planner/DWAPlannerROS"
# base_local_planner: "base_local_planner/TrajectoryPlannerROS"
base_global_planner: "global_planner/GlobalPlanner"
Originally posted by msadowski on ROS Answers with karma: 311 on 2019-07-11
Post score: 1
Original comments
Comment by billynugrahas on 2020-05-28:
hey there, have you found the solution?
Comment by msadowski on 2020-05-28:
not for this kind of robot. We've since moved to a circular robot which helped solve most of the issues in a narrow corridor like this.
