Revision history [back]

Collision issue

So I am a little confused, my robot plans the route fine but then piles in to the obstacles, the green line is always spot on what it needs to do, the SLAM positions the robot fine etc. but the actual route it takes (purple) takes it far too near obsticles

Second question, why is my /map never moving with my robot?

Collision issue

So I am a little confused, my robot plans the route fine but then piles in to the obstacles, the green line is always spot on what it needs to do, the SLAM positions the robot fine etc. but the actual route it takes (purple) takes it far too near obsticles

Second question, why is my /map never moving with my robot?

Collision issue

So I am a little confused, my robot plans the route fine but then piles in to the obstacles, the green line is always spot on what it needs to do, the SLAM positions the robot fine etc. but the actual route it takes (purple) takes it far too near obsticlesobstacles

Second question, why is my /map never moving with my robot?

I have a footprint, and collision enabled on the URDF. Could this be a motor control issue?

Collision issue

So I am a little confused, my robot plans the route fine but then piles in to the obstacles, the green line is always spot on what it needs to do, the SLAM positions the robot fine etc. but the actual route it takes (purple) takes it far too near obstacles

Second question, why is my /map never moving with my robot?

I have a footprint, and collision enabled on the URDF. Could this be a motor control issue?

local_costmap:
global_frame: /map # The global frame for the costmap to operate in. default /map
robot_base_frame: /scanmatcher_frame # The name of the frame for the base link of the robot. default base_link
update_frequency: 5.0 # The frequency in Hz for the map to be updated. default: 5.0
publish_frequency: 2.0 # The frequency in Hz for the map to be publish display information. default 0.0
static_map: false # Whether or not to use the static map to initialize the costmap. If the rolling_window parameter is set to true, this parameter must be set to false.  default: true
rolling_window: true # Whether or not to use a rolling window version of the costmap. If the static_map parameter is set to true, this parameter must be set to false.
width: 4.0 # The width of the map in meters. default 10
height: 4.0 # The height of the map in meters. default 10
resolution: 0.05 # The resolution of the map in meters/cell. default 0.05
transform_tolerance: 0.5

global_costmap:
global_frame: /map # The global frame for the costmap to operate in. default /map
robot_base_frame: /scanmatcher_frame # The name of the frame for the base link of the robot. default base_link
update_frequency: 1.0 # The frequency in Hz for the map to be updated. default: 5.0
publish_frequency: 0.5 # The frequency in Hz for the map to be publish display information. default 0.0
static_map: true # Whether or not to use the static map to initialize the costmap. If the rolling_window parameter is set to true, this parameter must be set to false.  default: true
transform_tolerance: 0.5

obstacle_range: 2.5 # The maximum range in meters at which to insert obstacles into the costmap using sensor data. default 2.5
raytrace_range: 3.0 # The maximum range in meters at which to raytrace out obstacles from the map using sensor data. default 3.0
footprint: [ [0.08, 0.08], [-0.08, 0.08], [-0.08, -0.08], [0.08, -0.08] ] # SThe footprint of the robot specified in the robot_base_frame coordinate frame as a list in the format: [ [x1, y1], [x2, y2], ...., [xn, yn] ]. The footprint specification assumes the center point of the robot is at (0.0, 0.0) in the robot_base_frame and that the points are specified in meters, both clockwise and counter-clockwise orderings of points are supported.
inflation_radius: 0.3 # The radius in meters to which the map inflates obstacle cost values. default 0.55

# voxel map configuration; z-voxels 0 are filled by bumpers and 1 by laser scan (kinect)
map_type: costmap # What map type to use. "voxel" or "costmap" are the supported types, with the difference between them being a 3D-view of the world vs. a 2D-view of the world.
#origin_z: 0.0 # The z origin of the map in meters. default 0.0
#z_resolution: 0.2 # The z resolution of the map in meters/cell. default 0.2
#z_voxels: 2 # The number of voxels to in each vertical column, the height of the grid is z_resolution * z_voxels. default 10
#publish_voxel_map: false # Whether or not to publish the underlying voxel grid for visualization purposes. default false

observation_sources: scan bump # A list of observation source names separated by spaces. This defines each of the <source_name> namespaces defined below.

scan: {data_type: LaserScan, topic: scan, marking: true, clearing: true, min_obstacle_height: 0.25, max_obstacle_height: 0.35}
bump: {data_type: PointCloud2, topic: mobile_base/sensors/bumper_pointcloud, marking: true, clearing: false, min_obstacle_height: 0.0, max_obstacle_height: 0.15}

TrajectoryPlannerROS:
# Robot Configuration Parameters
max_vel_x: 0.5 # 0.3 The maximum forward velocity allowed for the base in meters/sec default 0.5
min_vel_x: 0.1 #The minimum forward velocity allowed for the base in meters/sec. It is useful to specify this to guarantee that velocity commands sent to a mobile base are high enough to allow the base to overcome friction. default 0.1

max_vel_theta:  1.5  # 1.0 The maximum rotational velocity allowed for the base in radians/sec default 1
min_vel_theta: -1.5  # -1.0 The minimum rotational velocity allowed for the base in radians/sec default -1
min_in_place_vel_theta: 1.0 # 0.6 The minimum rotational velocity allowed for the base while performing in-place rotations in radians/sec default 0.4

acc_lim_x: 0.6 # The x acceleration limit of the robot in meters/sec^2 default  2.5
acc_lim_theta: 1.0 # The rotational acceleration limit of the robot in radians/sec^2 default 3.2

# Goal Tolerance Parameters
yaw_goal_tolerance: 3.14 # The tolerance in radians for the controller in yaw/rotation when achieving its goal  default: 0.05
xy_goal_tolerance: 0.15 # The tolerance in meters for the controller in the x & y distance when achieving a goal default: 0.10

# Forward Simulation Parameters
sim_time: 3.0 # The amount of time to forward-simulate trajectories in seconds  default: 1.0
vx_samples: 6 # The number of samples to use when exploring the x velocity space default: 3
vtheta_samples: 20 # The number of samples to use when exploring the theta velocity space default: 20

# 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. default false
pdist_scale: 0.6 # The weighting for how much the controller should stay close to the path it was given default: 0.6
gdist_scale: 0.8 # The weighting for how much the controller should attempt to reach its local goal, also controls speed default default: 0.8
occdist_scale: 0.01 # The weighting for how much the controller should attempt to avoid obstacles default 0.01
heading_lookahead: 0.325 # How far to look ahead in meters when scoring different in-place-rotation trajectories default: 0.32
dwa: true # Whether to use the Dynamic Window Approach (DWA)_ or whether to use Trajectory Rollout (NOTE: In our experience DWA worked as well as Trajectory Rollout and is computationally less expensive. It is possible that robots with extremely poor acceleration limits could gain from running Trajectory Rollout, but we recommend trying DWA first.) default true

# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05 # How far the robot must travel in meters before oscillation flags are reset default 0.05

# Differential-drive robot configuration
holonomic_robot: false


Collision issue

So I am a little confused, my robot plans the route fine but then piles in to the obstacles, the green line is always spot on what it needs to do, the SLAM positions the robot fine etc. but the actual route it takes (purple) takes it far too near obstacles

Second question, why is my /map never moving with my robot?

I have a footprint, and collision enabled on the URDF. Could this be a motor control issue?

 local_costmap:
global_frame: /map # The global frame for the costmap to operate in. default /map
robot_base_frame: /scanmatcher_frame # The name of the frame for the base link of the robot. default base_link
update_frequency: 5.0 # The frequency in Hz for the map to be updated. default: 5.0
publish_frequency: 2.0 # The frequency in Hz for the map to be publish display information. default 0.0
2.0
static_map: false # Whether or not to use the static map to initialize the costmap. If the rolling_window parameter is set to true, this parameter must be set to false.  default: true
rolling_window: true # Whether or not to use a rolling window version of the costmap. If the static_map parameter is set to true, this parameter must be set to false.
width: 4.0 # The width of the map in meters. default 10
height: 4.0 # The height of the map in meters. default 10
resolution: 0.05 # The resolution of the map in meters/cell. default 0.05
transform_tolerance: 0.5

global_costmap:
global_frame: /map # The global frame for the costmap to operate in. default /map
robot_base_frame: /scanmatcher_frame # The name of the frame for the base link of the robot. default base_link
update_frequency: 1.0 # The frequency in Hz for the map to be updated. default: 5.0
publish_frequency: 0.5 # The frequency in Hz for the map to be publish display information. default 0.0
0.5
static_map: true # Whether or not to use the static map to initialize the costmap. If the rolling_window parameter is set to true, this parameter must be set to false.  default: true
transform_tolerance: 0.5

obstacle_range: 2.5 # The maximum range in meters at which to insert obstacles into the costmap using sensor data. default 2.5
raytrace_range: 3.0 # The maximum range in meters at which to raytrace out obstacles from the map using sensor data. default 3.0
footprint: [ [0.08, 0.08], [-0.08, 0.08], [-0.08, -0.08], [0.08, -0.08] ] # SThe footprint of the robot specified in the robot_base_frame coordinate frame as a list in the format: [ [x1, y1], [x2, y2], ...., [xn, yn] ]. The footprint specification assumes the center point of the robot is at (0.0, 0.0) in the robot_base_frame and that the points are specified in meters, both clockwise and counter-clockwise orderings of points are supported.
inflation_radius: 0.3 # The radius in meters to which the map inflates obstacle cost values. default 0.55

# voxel map configuration; z-voxels 0 are filled by bumpers and 1 by laser scan (kinect)
map_type: costmap # What map type to use. "voxel" or "costmap" are the supported types, with the difference between them being a 3D-view of the world vs. a 2D-view of the world.
#origin_z: 0.0 # The z origin of the map in meters. default 0.0
#z_resolution: 0.2 # The z resolution of the map in meters/cell. default 0.2
#z_voxels: 2 # The number of voxels to in each vertical column, the height of the grid is z_resolution * z_voxels. default 10
#publish_voxel_map: false # Whether or not to publish the underlying voxel grid for visualization purposes. default false

observation_sources: scan bump # A list of observation source names separated by spaces. This defines each of the <source_name> namespaces defined below.

scan: {data_type: LaserScan, topic: scan, marking: true, clearing: true, min_obstacle_height: 0.25, max_obstacle_height: 0.35}
bump: {data_type: PointCloud2, topic: mobile_base/sensors/bumper_pointcloud, marking: true, clearing: false, min_obstacle_height: 0.0, max_obstacle_height: 0.15}

TrajectoryPlannerROS:
# Robot Configuration Parameters
max_vel_x: 0.5 # 0.3 The maximum forward velocity allowed for the base in meters/sec default 0.5
min_vel_x: 0.1 #The minimum forward velocity allowed for the base in meters/sec. It is useful to specify this to guarantee that velocity commands sent to a mobile base are high enough to allow the base to overcome friction. default 0.1

max_vel_theta:  1.5  # 1.0 The maximum rotational velocity allowed for the base in radians/sec default 1
min_vel_theta: -1.5  # -1.0 The minimum rotational velocity allowed for the base in radians/sec default -1
min_in_place_vel_theta: 1.0 # 0.6 The minimum rotational velocity allowed for the base while performing in-place rotations in radians/sec default 0.4
1.0

acc_lim_x: 0.6 # The x acceleration limit of the robot in meters/sec^2 default  2.5
0.6
acc_lim_theta: 1.0 # The rotational acceleration limit of the robot in radians/sec^2 default 3.2
1.0

# Goal Tolerance Parameters
yaw_goal_tolerance: 3.14 # The tolerance in radians for the controller in yaw/rotation when achieving its goal  default: 0.05
xy_goal_tolerance: 0.15 # The tolerance in meters for the controller in the x & y distance when achieving a goal default: 0.10

# Forward Simulation Parameters
sim_time: 3.0 # The amount of time to forward-simulate trajectories in seconds  default: 1.0
3.0
vx_samples: 6 # The number of samples to use when exploring the x velocity space default: 3
6
vtheta_samples: 20 # The number of samples to use when exploring the theta velocity space default: 20

# 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. default false
true
pdist_scale: 0.6 # The weighting for how much the controller should stay close to the path it was given default: 0.6
gdist_scale: 0.8 # The weighting for how much the controller should attempt to reach its local goal, also controls speed default default: 0.8
occdist_scale: 0.01 # The weighting for how much the controller should attempt to avoid obstacles default 0.01
heading_lookahead: 0.325 # How far to look ahead in meters when scoring different in-place-rotation trajectories default: 0.32
dwa: true # Whether to use the Dynamic Window Approach (DWA)_ or whether to use Trajectory Rollout (NOTE: In our experience DWA worked as well as Trajectory Rollout and is computationally less expensive. It is possible that robots with extremely poor acceleration limits could gain from running Trajectory Rollout, but we recommend trying DWA first.) default true

# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05 # How far the robot must travel in meters before oscillation flags are reset default 0.05

# Differential-drive robot configuration
holonomic_robot: false