Hi Roboticists,
Here is [video](https://youtu.be/eV6zFFAtSec), I'm using `dwa_local_planner` and it confuses at near to goal position. Especially, when goal point's X and footprint center's X are close, it confuses.
**UPDATE2:** Added new [video](https://youtu.be/u8bxz1sG5lo) and updated header of question.
**UPDATE:** Changed `/move_base/base_local_planner/dwa_local_planner`'s logger level from `Info` to `Debug` and now, `rqt_console` says something at struggling:
Velocity -0.600, 0.000, 0.442 discarded by cost function 0 with cost: -5.000000
Velocity -0.600, 0.000, 0.316 discarded by cost function 0 with cost: -5.000000
Velocity -0.600, 0.000, 0.189 discarded by cost function 0 with cost: -5.000000
Velocity -0.600, 0.000, 0.063 discarded by cost function 0 with cost: -5.000000
Evaluated 62 trajectories, found 32 valid
Velocity 0.600, 0.000, 1.200 discarded by cost function 0 with cost: -5.000000
Velocity 0.600, 0.000, 1.074 discarded by cost function 0 with cost: -5.000000
Velocity 0.600, 0.000, 0.947 discarded by cost function 0 with cost: -5.000000
Velocity 0.600, 0.000, 0.821 discarded by cost function 0 with cost: -5.000000
Velocity 0.600, 0.000, 0.695 discarded by cost function 0 with cost: -5.000000
Velocity 0.600, 0.000, 0.568 discarded by cost function 0 with cost: -5.000000
I've replaced footprint to square but the result didn't change. Here is its parameters:
DWAPlannerROS:
# Robot Configuration Parameters
acc_lim_x: 10.0 # (double, default: 2.5) The x acceleration limit of the robot in meters/sec^2
acc_lim_y: 0.0 # (double, default: 2.5)
acc_lim_theta: 20.0 # (double, default: 3.2)
acc_limit_trans: 1.0 #
max_trans_vel: 0.6 # (double, default: 0.55)
min_trans_vel: 0.02 # (double, default: 0.1)
trans_stopped_vel: 0.02 #
rot_stopped_vel: 0.02 #
max_vel_x: 0.6 # (double, default: 0.55)
min_vel_x: -0.6 # (double, default: 0.0)
max_vel_y: 0.0 # (double, default: 0.1)
min_vel_y: 0.0 # (double, default: -0.1)
max_rot_vel: 1.2 # (double, default: 1.0)
min_rot_vel: 0.02 # (double, default: 0.4)
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.01 # (double, default: 0.05)
xy_goal_tolerance: 0.07 # (double, default: 0.10)
latch_xy_goal_tolerance: false # (bool, default: false)
# Forward Simulation Parameters
sim_time: 0.5
sim_granularity: 0.05
angular_sim_granularity: 0.05
vx_samples: 3 # (integer, default: 3)
vy_samples: 1 # (integer, default: 10)
vtheta_samples: 20 # (integer, default: 20)
# controller_frequency: 10.0 # (double, default: 20.0)
# Trajectory Scoring Parameters
path_distance_bias: 32.0 # (double, default: 32.0)
goal_distance_bias: 24.0 # (double, default: 24.0)
occdist_scale: 0.01 # (double, default: 0.01)
# pdist_scale: 0.75
# gdist_scale: 0.8
forward_point_distance: 0.0 # 2.0 # 0.325
stop_time_buffer: 0.2 # (double, default: 0.2)
scaling_speed: 0.25 # (double, default: 0.25)
max_scaling_factor: 0.2 # (double, default: 0.2)
use_dwa: true
#Oscillation Prevention Parameters
oscillation_reset_dist: 0.05 # (double, default: 0.05)
oscillation_reset_angle: 0.05 #
prune_plan: false # (bool, default: true)
TrajectoryPlannerROS:
yaw_goal_tolerance: 0.01
acc_lim_th: 10.0
max_rotational_vel: 1.2
min_in_place_rotational_vel: -1.2
holonomic_robot: false
meter_scoring: true
Thank you.
↧
The Crazy DWAPlannerROS is confusing on global path's some parts
↧
Is there a flowchart or something like that for dwa_local_planner or base_local_planner?
Hi all,
Reading from code is complicating. And I can't found calling sequences for these functions:
UpdatePlanAndCosts(...);
checkTrajectory(...);
setPlan(...);
isGoalReached(...);
checkTrajectory(...);
computeVelocityCommands(...);
findBestPath(...);
...
etc.
↧
↧
Gmapping in a complex environment.
I am using a turtlebot2 with an ASUS XTION laser scanner and I am trying to develop autonomous mapping functionality but I am running into a lot of issues with path planning. The robot often gets stuck and is unable to find a path to its goal. I am currently testing in an office environment that has a lot of complex obstacle features (chair legs, table legs, human legs, etc.) and I was wondering if these features might be affecting the performance of the path planner? There are also a few ceiling-to-floor windows which may be confusing the laser scanner.
Does anyone know the limitations of the DWA local planner in complex environments? In videos I see online, people often create very structured maze like environments which make it easy for the robot to navigate.
EDIT:
The error I get from move_base is "Aborting because a valid plan could not be found. Even after executing all recovery behaviors." This occurs once the robot has mapped out a small area and gets stuck. It may be trying to send a goal to a location not in its vicinity but I'm not sure.
Also, I tend to get the warning "scan matching failed using odometry" when using gmapping so maybe this has something to with it.
Finally, I often get the error "You must specify at least three points for the robot footprint,reverting to previous footprint" even though my robot_radius is set in the costmap_common_params file.
↧
local planner orientation
Hello!
We developed a global planner with orientations here in the lab since navfn or global planner don't generate such.
However we now found the problem that local planner dwa and eband both ignore the provided orientations.
Is there a way to configure [dwa](http://wiki.ros.org/dwa_local_planner) or [eband](http://wiki.ros.org/eband_local_planner) local planner to follow intermediate orientations? (not only the final one) or do we have to write our own local planner?,
Just for reference we have a omnidirectional mobile base (youBot) which has non circular footprint.
thanks for the help
Oscar
↧
DWAPlannerROS making spiral trajectory while following global path
Hi all,
I'm trying to configure dwa planner for a custom skid drive platform, but I'm unable to get a good behaviour of the planner. As it tries to follow the global path, the planner always chooses an almost circular trajectory, alternating forward and backward movements. As result, the platform ends following the path in kind of a spiral trajectory. This behaviour can be observed in the following [video](https://youtu.be/uutNtx1kKLc).
My initial guess was that it's trying to get as fast as possible to the path, so I've tried to reduce *path_distance_bias* while increasing *goal_distance_bias*. My hope was that it would tend more towards the goal and less to the path, thus, avoiding turning so hard. However, this change didn't show any improvement.
We need DWA, as TrajectoryPlannerROS is not able to make backwards trajectories and has a hard time achieving goals with our required precision.
Any help will be appreciated.
I'm using ROS Hydro on ubuntu 12.04. Relevant configuration files:
**DWA params:**
DWAPlannerROS:
acc_lim_x: 2.5
acc_lim_y: 0.0 # Not holonomic == 0
acc_lim_th: 3.2
max_trans_vel: 0.55
min_trans_vel: 0.1
max_vel_x: 0.55
min_vel_x: -0.55
max_vel_y: 0.0 # Not holonomic == 0
min_vel_y: 0.0 # Not holonomic == 0
max_rot_vel: 1.0
min_rot_vel: 0.3
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.05
xy_goal_tolerance: 0.10
latch_xy_goal_tolerance: false
# Forward Simulation Parameters
sim_time: 1.7
sim_granularity: 0.025
vx_samples: 3
vy_samples: 0 # Not holonomic
vtheta_samples: 20
controller_frequency: 20.0
penalize_negative_x: false
# Trajectory Scoring Parameters
path_distance_bias: 0.1 #32.0
goal_distance_bias: 50 #24.0
occdist_scale: 0.1 #0.01
forward_point_distance: 0.325
stop_time_buffer: 0.2
scaling_speed: 0.25
max_scaling_factor: 0.2
# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05
# Global Plan Parameters
prune_plan: true
**move_base params**
base_global_planner: navfn/NavfnROS
base_local_planner: dwa_local_planner/DWAPlannerROS
recovery_behaviors: [{name: conservative_reset, type: clear_costmap_recovery/ClearCostmapRecovery}, {name: rotate_recovery, type: rotate_recovery/RotateRecovery}, {name: aggressive_reset, type: clear_costmap_recovery/ClearCostmapRecovery}]
controller_frequency: 10.0
planner_patience: 5.0
controller_patience: 15.0
conservative_reset_dist: 3.0
recovery_behavior_enabled: false
clearing_rotation_allowed: false
shutdown_costmaps: false
oscillation_timeout: 0.0
oscillation_distance: 0.5
planner_frequency: 0.5
↧
↧
How to use move_base with the DWA planner as the local planner in kinetic
Hello,
I am really confused as how to use the DWA for local planning with move_base.
It seems that dwa is now a bool parameter of the base_local_planner/TrajectoryPlannerROS. But then how to access the dw_local_planner parameters, such as forward_point_distance?
↧
Turtlebot + Frontier Exploration: Turning in Place at the Start
I have curious issues using the frontier_exploration package on my Turtlebot and would appreciate anyone helping me understand better what is going on under the hood.
Firstly, this is a [simulated run on Gazebo](https://youtu.be/q9xztO5I0Zk) of my robot setup.
After I ask the robot to go forth and explore, it begins by turning in place. This invariably happens no matter what starting exploration point I pick. I also get the following error messages, which probably point at the problem:
[ WARN] [1466389076.511953487, 657.183000000]: Please select an initial point for exploration inside the polygon
[ INFO] [1466389079.366449392, 658.110000000]: Sending goal
[ INFO] [1466389079.574537491, 658.152000000]: Region boundary set
[ INFO] [1466389086.897870100, 660.082000000]: Got new plan
[ERROR] [1466389086.898554785, 660.082000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389087.596126130, 660.278000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389088.219151245, 660.484000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389088.984638998, 660.678000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389089.730673868, 660.880000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ INFO] [1466389090.284299471, 661.110000000]: Got new plan
[ERROR] [1466389090.284972952, 661.110000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389090.755919337, 661.278000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389091.294571326, 661.478000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389091.920927691, 661.678000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389092.427586470, 661.878000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ INFO] [1466389092.912826709, 662.078000000]: Got new plan
[ERROR] [1466389092.913268554, 662.078000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389093.670462783, 662.280000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389094.369503898, 662.478000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389095.643821480, 662.678000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ INFO] [1466389096.474418339, 662.878000000]: Got new plan
[ERROR] [1466389096.474903849, 662.878000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389097.468142710, 663.078000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389098.693172111, 663.278000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389099.417643831, 663.478000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389100.220558345, 663.678000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389100.953090959, 663.878000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ INFO] [1466389101.617699327, 664.083000000]: Got new plan
[ERROR] [1466389101.618116982, 664.083000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389102.286638000, 664.278000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389103.214008032, 664.478000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ERROR] [1466389104.448767752, 664.679000000]: None of the 0 first of 0 (0) points of the global plan were in the local costmap and free
[ INFO] [1466389105.521163815, 664.878000000]: Got new plan
[ INFO] [1466389113.576508452, 666.078000000]: Got new plan
[ INFO] [1466389119.446550737, 667.281000000]: Got new plan
[ INFO] [1466389121.907575527, 667.878000000]: Goal reached
Beyond this point, everything chugs along quite smoothly. Notice at the start there are no debug messages indicating recovery behavior - it just turns for some other reason.
Source code reveals that the error messages are printed out in base_local_planner/src/map_grid.cpp. When I run regular navigation tutorials, using the same dwa local planner, I do not get the error messages.
Here are my setup files, cobbled together from various sources:
exploration.launch:
costmap_common_params.yaml:
max_obstacle_height: 0.60
footprint: [[0.2, 0.2], [0.2, -0.2], [-0.2, -0.2], [-0.2, 0.2]]
update_frequency: 1.0
publish_frequency: 0.5
resolution: 0.05
transform_tolerance: 0.5
robot_base_frame: base_footprint
inflation_radius: 0.4
obstacle_range: 3.5
raytrace_range: 3.5
obstacle_layer:
observation_sources: laser bump
laser: {data_type: LaserScan, clearing: true, marking: true, topic: scan, inf_is_valid: true}
bump: {data_type: PointCloud2, topic: mobile_base/sensors/bumper_pointcloud, marking: true, clearing: false, min_obstacle_height: 0.0, max_obstacle_height: 0.15}
inflation_layer:
enabled: true
static_layer:
enabled: true
map_topic: map
subscribe_to_updates: true
costmap_exploration.yaml:
track_unknown_space: true
global_frame: map
static_map: true
rolling_window: false
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: explore_boundary, type: "frontier_exploration::BoundedExploreLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
explore_boundary:
resize_to_boundary: false
frontier_travel_point: middle
explore_clear_space: false
move_base.launch.xml:
local_costmap_params.yaml:
local_costmap:
global_frame: odom
static_map: false
rolling_window: true
width: 4.0
height: 4.0
plugins:
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
global_costmap_params.yaml:
global_costmap:
global_frame: map
rolling_window: false
track_unknown_space: true
static_map: true
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
move_base_params.yaml:
shutdown_costmaps: false
controller_frequency: 5.0
controller_patience: 3.0
recovery_behaviour_enabled: true
planner_frequency: 1.0
planner_patience: 5.0
oscillation_timeout: 10.0
oscillation_distance: 0.2
base_local_planner: "dwa_local_planner/DWAPlannerROS"
base_global_planner: "navfn/NavfnROS"
dwa_local_planner_params.yaml:
DWAPlannerROS:
max_vel_x: 0.5 # 0.55
min_vel_x: 0.0
max_vel_y: 0.0
min_vel_y: 0.0
max_trans_vel: 0.5
min_trans_vel: 0.1
trans_stopped_vel: 0.1
max_rot_vel: 5.0
min_rot_vel: 0.4
rot_stopped_vel: 0.4
acc_lim_x: 1.0
acc_lim_theta: 2.0
acc_lim_y: 0.0
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.3
xy_goal_tolerance: 0.15
# Forward Simulation Parameters
sim_time: 1.0
sim_granularity: 0.025
vx_samples: 6
vy_samples: 1
vtheta_samples: 20
# Trajectory Scoring Parameters
path_distance_bias: 64.0
goal_distance_bias: 24.0
occdist_scale: 1.0
forward_point_distance: 0.325
stop_time_buffer: 0.2
scaling_speed: 0.25
max_scaling_factor: 0.2
meter_scoring: true
# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05 # 0.05
publish_traj_pc : true
publish_cost_grid_pc: true
global_frame_id: odom
navfn_global_planner_params.yaml:
NavfnROS:
visualize_potential: false
allow_unknown: true
planner_window_x: 0.0
planner_window_y: 0.0
default_tolerance: 0.1
global_planner_params.yaml:
GlobalPlanner:
old_navfn_behavior: false
use_quadratic: true
use_dijkstra: false
use_grid_path: false
allow_unknown: true
planner_window_x: 0.0
planner_window_y: 0.0
default_tolerance: 0.25
publish_scale: 100
planner_costmap_publish_frequency: 0.0
lethal_cost: 253
neutral_cost: 50
cost_factor: 3.0
publish_potential: true
The simulated robot in the video can stay localized with the turns at the start because I have artificially widened its vision, thereby vastly improving localization ability. My real-world setup consists of a Asus Xtion Pro with a narrower view. In simulations with this actual FOV, turning in place at the start causes the robot to get lost very quickly and the whole scenario to fail.
I would appreciate any pointers on how I should about investigating this, and where to start looking. Thanks!
↧
move_base turns clockwise when counterclockwise would be faster
In both of the scenarios depicted below, by robot turns clockwise. counterclockwise is obviously much faster. It will however turn counterclockwise if the goal is very close to in front of the robot, around 30deg maybe. Anything past that turns the other way.
I have min_rot_vel set to 0.07, since according to the DWA_local_planner wiki, it's an absolute value.


↧
Hokuyo laser - Turtlebot costmap updation error
Hello people,
We have a turtlebot(kobuki base) and have connected Hokuyo laser to it following the instructions from these links.
- http://wiki.ros.org/turtlebot/Tutorials/hydro/Adding%20a%20Hokuyo%20laser%20to%20your%20Turtlebot
- https://github.com/hcrlab/wiki/blob/master/turtlebot/adding_hokuyo_laser.md
Previously when we tested AMCL with Kinect (as available with the turtlebot), the indoor navigation was fine and the map was updated with dynamic obstacles(like person walking in front of it, sudden obstacle not available in map) introduced then and there, and the turtlebot was able to avoid them and reach the goal.
When we tried the same with Hokuyo laser, we were able to map the area using gmapping, do AMCL as well with it and the robot was able to reach the goal. But the robot was not able to update itself with dynamic obstacles introduced. It was able to see only the static mapped obstacles and couldn't avoid dynamic obstacles while reaching its goal. Not sure if any navigation parameters are to be modified. Could anyone please help on the same???
↧
↧
robot unable to rotate in place for dwa_local_planner especially for slow rotational velocities
Hi all,
I am using the dwa_planner as local planner with very low velocities. The navigation is basically working very good. There is only one problem. In-place-rotations of the robot, most commonly at the beginning of navigation, are resulting in an oscillating behaviour. This leads to an endless loop of recovery behavior or, in case one disabled the recovery, it leads to the abortion of navigation. For example if one set the goal in the opposite direction of the roboters pose, the robot will instantly start to oscillate. If one sets the goal in 90 degrees or even a little bit less the robot will start rotating in goal direction but will abort before it could start to drive forward.
I could reconstruct this behaviour with the turtlebot_stage simulation when adjusting min_rot_vel to 0.05 and max_rot_vel to 0.1.
I am using ros indigo.
These are my current parameters:
DWAPlannerROS: {
acc_lim_theta: 2.0, acc_lim_x: 0.5, acc_lim_y: 0.0, acc_limit_trans: 0.1,
angular_sim_granularity: 0.1, forward_point_distance: 0.325, global_frame_id: odom,
goal_distance_bias: 24.0, holonomic_robot: false, max_rot_vel: 0.1, max_scaling_factor: 0.2,
max_trans_vel: 0.5, max_vel_x: 0.1, max_vel_y: 0.0, min_rot_vel: 0.05, min_trans_vel: 0.1,
min_vel_x: 0.0, min_vel_y: 0.0, occdist_scale: 0.5, oscillation_reset_angle: 0.2,
oscillation_reset_dist: 0.05, path_distance_bias: 64.0, prune_plan: false,
publish_cost_grid_pc: true, publish_traj_pc: true, restore_defaults: false, rot_stopped_vel: 0.4,
scaling_speed: 0.25, sim_granularity: 0.1, sim_time: 2.0, stop_time_buffer: 0.2,
trans_stopped_vel: 0.1, use_dwa: true, vth_samples: 20, vtheta_samples: 20, vx_samples: 6,
vy_samples: 1, xy_goal_tolerance: 0.15, yaw_goal_tolerance: 0.1
}
I know there is a similar question: [robot unable to rotate in place for dwa_local_planner](http://answers.ros.org/question/210914/robot-unable-to-rotate-in-place-for-dwa_local_planner/ "robot unable to rotate in place for dwa_local_planner") There it is mentioned that dwa_planner cannot perform a rotate in spot motion. It will always trying to perform an arc motion. One just need to tune
path_distance_bias: 1.0
goal_distance_bias: 0.8
occdist_scale: 0.01
This won't stop the oscillation and the abortion of navigation. Still it helps to shorten time the robot needs to rotate before driving forward, but comes with the disadvantage of driving detours.
Please let me know if you need more information from me. Any help will be appreciated.
Thanks in advance.
Clemens Weißenberg
↧
Error in move base : Aborting because the robot appears to be oscillating over and over. Even after executing all recovery behaviors"
I have created my navigating tracked mobile robot. When i give a simple goal to the robot in RVIZ path planning was done successfully. But the robot did not move. Instead of moving the error message was prompted after few seconds as Aborting because the robot appears to be oscillating over and over. Even after executing all recovery behaviors". Can anyone give me a proper solution for this. In here i have attached all parameter files, rqt graph of active topics and some screenshots in RVIZ.
local_costmap_params.ymail
local_costmap:
global_frame: odom
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 2.0
static_map: false
rolling_window: true
width: 1.0
height: 1.0
resolution: 0.05
transform_tolerance: 0.5
plugins:
- {name: obstacles, type: "costmap_2d::VoxelLayer"}
- {name: inflater, type: "costmap_2d::InflationLayer"}
global_costmap_params.yaml
global_costmap:
global_frame: /map
robot_base_frame: base_link
update_frequency: 1.0
publish_frequency: 0.5
static_map: true
transform_tolerance: 0.5
costmap_common_params.yaml
obstacle_range: 2.5
raytrace_range: 3.0
#footprint: [[x0, y0], [x1, y1], ... [xn, yn]]
footprint: [[-0.2,-0.2],[-0.2,0.2], [0.2, 0.2], [0.2,-0.2]]
#robot_radius: 0.22545
robot_radius: 0.4002
#cost_scaling_factor and inflation_radius were now moved to the inflation_layer ns
inflation_layer:
enabled: true
cost_scaling_factor: 10.0 # exponential rate at which the obstacle cost drops off (default: 10)
inflation_radius: 0.30 # max. distance from an obstacle at which costs are incurred for planning paths.
obstacle_layer:
enabled: true
min_obstacle_height: 0.0
max_obstacle_height: 0.6
origin_z: 0.0
z_resolution: 0.2
z_voxels: 2
unknown_threshold: 15
mark_threshold: 0
combination_method: 1
track_unknown_space: true #true needed for disabling global path planning through unknown space
obstacle_range: 2.5
raytrace_range: 3.0
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
dwa_local_planner_params.yaml
DWAPlannerROS:
# Robot Configuration Parameters - Kobuki
max_vel_x: 0.55 # 0.55
min_vel_x: 0.0
max_vel_y: 0.4 # diff drive robot
min_vel_y: 0.0 # diff drive robot
max_trans_vel: 0.38 # choose slightly less than the base's capability
min_trans_vel: 0.10 # this is the min trans velocity when there is negligible rotational velocity
trans_stopped_vel: 0.1
# Warning!
# do not set min_trans_vel to 0.0 otherwise dwa will always think translational velocities
# are non-negligible and small in place rotational velocities will be created.
#max_rot_vel: 5.0 # choose slightly less than the base's capability
max_rot_vel: 2.0 # Very slow for exploration!
min_rot_vel: 0.4 # this is the min angular velocity when there is negligible translational velocity
rot_stopped_vel: 0.4
acc_lim_x: 0.5 # maximum is theoretically 2.0, but we
acc_lim_theta: 2.0
acc_lim_y: 0.0 # diff drive robot
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.1 # 0.05
xy_goal_tolerance: 0.15 # 0.10
# latch_xy_goal_tolerance: false
# Forward Simulation Parameters
sim_time: 1.0 # 1.7
vx_samples: 6 # 3
vy_samples: 1 # diff drive robot, there is only one sample
vtheta_samples: 20 # 20
# Trajectory Scoring Parameters
path_distance_bias: 32.0 # 32.0 - weighting for how much it should stick to the global path plan
goal_distance_bias: 24.0 # 24.0 - wighting for how much it should attempt to reach its goal
occdist_scale: 0.50 # 0.01 - weighting for how much the controller should avoid obstacles
forward_point_distance: 0.325 # 0.325 - how far along to place an additional scoring point
stop_time_buffer: 0.2 # 0.2 - amount of time a robot must stop in before colliding for a valid traj.
scaling_speed: 0.25 # 0.25 - absolute velocity at which to start scaling the robot's footprint
max_scaling_factor: 0.2 # 0.2 - how much to scale the robot's footprint when at speed.
# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05 # 0.05 - how far to travel before resetting oscillation flags
# Debugging
publish_traj_pc : true
publish_cost_grid_pc: true
global_frame_id: odom
# Differential-drive robot configuration - necessary?
holonomic_robot: false
prune_plan: true # May help with Auto Explore.
**move_base.launch.xml**
**rqt graphs of active topics and nodes**
[Link1](https://www.dropbox.com/s/b2j2u9hg9tf2gtu/rosgraph.png?dl=0)
**RVIZ view after giving a simple goal**
[Link2](https://www.dropbox.com/s/eniklsp4pymtmql/Screenshot%20from%202016-08-31%2001%3A41%3A36.png?dl=0)
**Error message**
[Link 3](https://www.dropbox.com/s/tbp3tts7ps66zyy/14287735_1077947105653397_544479295_n.jpg?dl=0)
**Velocity messeges published on the robot base by /cmd_vel topic**
[Link 4](https://www.dropbox.com/s/ikw0jho1hf9ym30/14287515_1077947015653406_502357658_n.jpg?dl=0)
Can anyone help please....
↧
Difference between path_distance_bias and pdist_scale
I noticed that in [base_local_planner](http://wiki.ros.org/base_local_planner) there are parameters `pdist_scale` and `gdist_scale`.
In [dwa_local_planner](http://wiki.ros.org/dwa_local_planner) there are parameters `path_distance_bias` and `goal_distance_bias`.
These parameters seem the same. Is there any difference? (If not, what is the reason for different names).
↧
DWA vs SBPL lattice planner for local planning?
Hello,
I intend to perform autonomous navigation on an ackermann-like robot (a car, actually). Assuming the global planner will give a path to follow by providing a list of waypoints to be reached, I want the local planner to drive the car along those intermediate points.
I have found that there exists a Dynamic Window Approach (DWA) local planner that takes into account the dynamic constraints of the robot to calculate a feasible local path. Modifying this planner to satisfy the dynamic constraints of an ackermann model seems a possible solution. In fact, this is the solution that has been adopted in some similar projects.
But I was thinking that it is very similar to what the SBPL lattice planner does: it takes into account the model of the robot and it creates a lattice with the possible states that can be reached. Nevertheless, the SBPL lattice planner is generally only used for global planning. I read [this paper](http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7359518) in which SBPL was used for both local and global planning.
My question is, what are the advantages of using DWA over SBPL as the local planner? I think that the biggest advantage is that DWA calculates the next velocity command for a given period of time.
Any additional suggestions are welcome.
Regards.
↧
↧
dwa_local_planner unable to make narrow U turn
Hi all,
things work perfectly when the robot goes straight, turning, or making wide U turns. However, I'm facing an issue that the robot stuck at certain location when its trying to make narrow U turn as shown in this [video](https://www.youtube.com/watch?v=dVbUG0zQvYA&feature=youtu.be).
Below is my dwa_local_planner parameters.
planner_frequency: 0.25
controller_frequency: 10.0
DWAPlannerROS:
max_trans_vel: 0.25
min_trans_vel: 0.05
max_vel_x: 0.25
min_vel_x: -0.05
max_rot_vel: 0.6
min_rot_vel: 0.2
acc_lim_x: 2.5
acc_lim_theta: 6.0
occdist_scale: 0.01
oscillation_reset_dist: 0.05
oscillation_reset_angle: 0.2
path_distance_bias: 60
sim_time: 2.0
sim_granularity: 0.1
angular_sim_granularity: 0.1
vx_samples: 3
vy_samples: 1 # zero for a differential drive robot
vtheta_samples: 20
dwa: true
Did anyone face the same issue i'm facing? If so, can you explain what is happening?
Thanks a lot, Will
↧
I have trouble changing the velocity of my robot.
Now,I'm studying ROS and using and my ROS robot,kobuki. However,I have trouble changing the velocity of the robot!
I set the max_vel_x value to 0.1 of "kobuki_navigation/param/dwa_local_planner_params.yaml" , and I launch ROS nodes with "kobuki_navigation/launch/kobuki_navigation.launch".Then the Terminal window displays "/move_base/DWAPlannerROS/max_vel_x: 0.1" in the parameters list.
However,when I operate my ROS robot with "2D Nav Goal" of RVIZ, the velocity of my robot is obviously faster than 0.1 m/s! I checked topic by "rostopic echo /cmd_vel",and then it shows "**linier: x: 0.55**"!! **Why I can't change the velocity of my robot** and **what is the "0.55" of "linier: x: 0.55**"?
(I tried setting not only 0.1 but also the other "max_vel_x" value, for example 0.2, 0.3, the result is the same. )
Can you please give me information on that?
----------
**”Execution environment”**
OS:ubuntu 14.04LTS
ROSver:indigo
----------
I'll show "**dwa_local_planner_params.yaml**" and "**kobuki_navigation.launch**" below.
Here is "dwa_local_planner_params.yaml "
DWAPlannerROS:
# Robot Configuration Parameters - Kobuki
max_vel_x: 0.1
min_vel_x: 0.0
max_vel_y: 0.1
min_vel_y: 0.0
max_trans_vel: 0.1
min_trans_vel: 0.1
trans_stopped_vel: 0.1
max_rot_vel: 1.0
min_rot_vel: 0.4
rot_stopped_vel: 0.4
acc_lim_x: 0.05
acc_lim_theta: 2.0
acc_lim_y: 0.0
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.3
xy_goal_tolerance: 0.03
# Forward Simulation Parameters
sim_time: 1.0
vx_samples: 6
vy_samples: 1
vtheta_samples: 20
# Trajectory Scoring Parameters
path_distance_bias: 64.0
goal_distance_bias: 24.0
occdist_scale: 0.5
forward_point_distance: 0.325
stop_time_buffer: 0.2
scaling_speed: 0.25
max_scaling_factor: 0.2
# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05
# Debugging
publish_traj_pc : true
publish_cost_grid_pc: true
global_frame_id: odom
meter_scoring: true
Here is "kobuki_navigation.launch".
↧
Robot can not avoid obstacle in navigation stack
Hi,
I am using ros-indigo on ubuntu 12.04 LTS. I am trying to use navigation stack, but I have some problem.
My robot can move "Initial Pose" to "goal", But can't avoid obstacles. Whether the obstacle require plugins (costmap_2d::StaticLayer) to be inserted in configuration file. Please can one suggest me asap. Thank's in advanced.
My configuration files are as following:
1) common_costmap_params.yaml
obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[-0.20, -0.20], [-0.20, 0.20], [0.20, 0.20], [0.20, 0.20]]
footprint_padding : 0.03
inflation_radius: 0.30
cost_scaling_factor: 1
map_type: costmap
max_obstacle_height: 1.0
min_obstacle_height: 0.65
transform_tolerance: 10.0
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: sensor, data_type: LaserScan, topic: scan, marking: true, clearing: true, observation_persistence: 0.0, expected_update_rate: 0.0, max_obstacle_height: 1.0, min_obstacle_height: 0.65, obstacle_range: 2.5, raytrace_range: 3.0, inf_is_valid: false}
2) global_costmap_params.yaml
global_costmap:
global_frame: /map
robot_base_frame: /base_link
update_frequency: 3.0 #20 3
publish_frequency: 2.0 #20 2
static_map: true
rolling_window : true
width: 10.0
height: 10.0
resolution: 0.1
3) local_costmap_params.yaml
local_costmap:
global_frame: /map
robot_base_frame: /base_link
update_frequency: 8.0 #10
publish_frequency: 6.0 #10
static_map: false
rolling_window: true
width: 4 #10.0
height: 4 #10.0
resolution: 0.01 #0.05
4) dwa_local_planner.yaml
DWAPlannerROS:
max_vel_x: 0.1099
min_vel_x: -0.1099
max_vel_y: 0.0
min_vel_y: 0.0
acc_lim_th: 0.01099
acc_lim_x: 0.07999
acc_lim_y: 0.0 #0.0
max_trans_vel: 0.0999
min_trans_vel: 0.0199
max_rot_vel: 0.05099
min_rot_vel: 0.01999
rot_stopped_vel: 0.02
sim_time: 1.7
vx_samples: 10
vy_samples: 1
vtheta_samples: 40
forward_point_distance: 0.0 # this value is being used as a cost value for robot alignment to the path
holonomic_robot: false
meter_scoring: true
dwa: true
yaw_goal_tolerance: 0.1
xy_goal_tolerance: 0.3
latch_xy_goal_tolerance: true
publish_cost_grid: true
path_distance_bias: 32.0
goal_distance_bias: 24.0
occdist_scale: 0.1
stop_time_buffer: 2.0
oscillation_reset_dist: 0.1
prune_plan: false
5) move_base_params.yaml
shutdown_costmaps: false
controller_frequency: 1.0
controller_patience: 1.0
planner_frequency: 1.0
planner_patience: 1.0
conservative_reset_dist: 0.2 #distance from an obstacle at which it will unstuck itself
↧
navigation with range_sensor_layer in navigation_stack ?
I have an rc car with arduino as speed controller and computer being nvidia tk1. I want to implement a collision avoidance. I have 5 Ultrasonic sensors mounted in front of rc car with odometry and IMU sensors. I am not using any laser scanner. Is this a feasible with range_sensor_layer ?
↧
↧
Is it normal behavior for local planners to ignore static obstacles if no pointcloud or laserscan data is being published?
I have tried the following local planners:
1. base_local_planner
2. dwa local planner
3. teb_local_planner
and all of them are ignoring obstacles on a static map, The global planners on the other hand never generate a path that would cause a collision with any obstacle.
It is noteworthy that I am not using kinect or a laser scanner so can't possibly publish pointcloud or laserscan messages.
↧
Is it possible to replace the local planner in the default ROS Navigation stack to one that uses reinforcement learning?
I'm building a driverless car and the current problem is the TEB Local Planner.
I was wondering if it is possible to replace with an RL agent, and whether this has been done before.
↧
Using the Move_base package with only a local planner
Hi All,
I'm currently designing a mobile robot that is required to follow an object within 2 meters. Currently, the mobile robot is able to identify the object, its distance from the object, and its orientation with respect to the object - this is enough information for me to set a navigation goal relative to the mobile robots location. The robot will be following the object into unknown environments, we can assume these environments will not be mapped.
For this application I believe it should be satisfactory to use a local planner to reach the short distance goal while avoiding any obstacles along the way.
I would like to take advantage of the dwa_local_planner package within the move_base package but I am unsure if move_base can be used without a global planner and without a map.
I would appreciate any advice,
Thanks for your help!
↧