0
$\begingroup$

Rosanswers logo

Hi all,

I have a question regarding my robot rotating often while using frontier exploration, also it rotates just before it reaches the goal?

also the costmap does mark and clear with the laser scan (asus xtion- depthimage_to_laserscan) but the ultrasonic sensor does not mark or clear the costmap?

(based on husky exploration)

Is there anything wrong with the configuration??

costmap_common.yaml

footprint: [[-0.230,-0.16],[-0.230, 0.16],[0.230,0.16],[0.23,-0.16]]
footprint_padding: 0.01

robot_base_frame: base_link
update_frequency: 3.0
publish_frequency: 2.0
transform_tolerance: 0.5

resolution: 0.099

obstacle_range: 1.5
raytrace_range: 1.5

#layer definitions
static:
    map_topic: /map
    subscribe_to_updates: true

obstacles_laser:
    observation_sources: laser
    laser: {data_type: LaserScan, clearing: true, marking: true, topic: scan, inf_is_valid: true}
    expected_update_rate: 0.07

inflation:
    inflation_radius: 0.05
range_sensor_layer:
 expected_update_rate: 0.125
 clear_threshold:     0.1
 mark_threshold:      0.1
 no_readings_timeout: 0.2
 topics: ["/ultrasound1"]

costmap_exploration.yaml

track_unknown_space: true
global_frame: map
rolling_window: false

plugins: 
- {name: external,            type: "costmap_2d::StaticLayer"}
- {name: explore_boundary,    type: "frontier_exploration::BoundedExploreLayer"}
#Can disable sensor layer if gmapping is fast enough to update scans
- {name: obstacles_laser,     type: "costmap_2d::ObstacleLayer"}
- {name: inflation,           type: "costmap_2d::InflationLayer"}

explore_boundary:
  resize_to_boundary: false
  frontier_travel_point: middle
  #set to false for gmapping, true if re-exploring a known area
  explore_clear_space: false

local_costmap.yaml

global_frame: odom
rolling_window: true

plugins:
  - {name: obstacles_laser,           type: "costmap_2d::ObstacleLayer"}
  - {name: range_sensor_layer, type: "range_sensor_layer::RangeSensorLayer"}
  - {name: inflation,                 type: "costmap_2d::InflationLayer"}

global_costmap.yaml

global_frame: odom
rolling_window: true

plugins:
  - {name: obstacles_laser,           type: "costmap_2d::ObstacleLayer"}
  - {name: range_sensor_layer, type: "range_sensor_layer::RangeSensorLayer"}
  - {name: inflation,                 type: "costmap_2d::InflationLayer"}

planner.yaml

recovery_behaviour_enabled: true

NavfnROS:
  allow_unknown: true # Specifies whether or not to allow navfn to create plans that traverse unknown space.
  default_tolerance: 0.5 # A tolerance on the goal point for the planner.

TrajectoryPlannerROS:
  # Robot Configuration Parameters
  acc_lim_x: 15.0
  acc_lim_theta:  15.0

  max_vel_x: 0.15
  min_vel_x: 0.8

  max_vel_theta: 0.5
  min_vel_theta: -0.5
  min_in_place_vel_theta: 0.7

  holonomic_robot: false
  escape_vel: -0.2

  # Goal Tolerance Parameters
  yaw_goal_tolerance: 0.2
  xy_goal_tolerance: 0.3
  latch_xy_goal_tolerance: false

  # Forward Simulation Parameters
  sim_time: 1.0
  sim_granularity: 0.02
  angular_sim_granularity: 0.02
  vx_samples: 6
  vtheta_samples: 20
  penalize_negative_x: true
  controller_frequency: 7.0

  # 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.01 #The weighting for how much the controller should attempt to avoid obstacles. default was0.5

  pdist_scale: 0.4  #     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 0.8

  heading_lookahead: 0.25  #How far to look ahead in meters when scoring different in-place-rotation trajectories

  heading_scoring: true  #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: false #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

DWAPlannerROS:
  # Robot configuration parameters  
  acc_lim_x: 2.5
  acc_lim_y: 0
  acc_lim_th: 3.2

  max_vel_x: 0.5
  min_vel_x: 0.0
  max_vel_y: 0
  min_vel_y: 0

  max_trans_vel: 0.5
  min_trans_vel: 0.1
  max_rot_vel: 1.0
  min_rot_vel: 0.2

  # Goal Tolerance Parameters
  yaw_goal_tolerance: 0.1
  xy_goal_tolerance: 0.2
  latch_xy_goal_tolerance: false



  # # Forward Simulation Parameters
  # sim_time: 2.0
  # sim_granularity: 0.02
  # vx_samples: 6
  # vy_samples: 0
  # vtheta_samples: 20
  # penalize_negative_x: true

  # # Trajectory scoring parameters
  # path_distance_bias: 32.0 # The weighting for how much the controller should stay close to the path it was given

  # goal_distance_bias: 24.0 # The weighting for how much the controller should attempt to reach its local goal, also controls speed
  # occdist_scale: 0.01 # The weighting for how much the controller should attempt to avoid obstacles
  # forward_point_distance: 0.325 # The distance from the center point of the robot to place an additional scoring point, in meters
  # stop_time_buffer: 0.2  # The amount of time that the robot must stThe absolute value of the veolicty at which to start scaling the robot's footprint, in m/sop before a collision in order for a trajectory to be considered valid in seconds
  # scaling_speed: 0.25 # The absolute value of the veolicty at which to start scaling the robot's footprint, in m/s
  # max_scaling_factor: 0.2 # The maximum factor to scale the robot's footprint by

Originally posted by miguel on ROS Answers with karma: 170 on 2015-09-29

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I Solved the issue, the acceleration limits in the trajectory planner were too high. Once they were decreased and find tuned to give the best robot movement robot does not rotate anymore.


Originally posted by miguel with karma: 170 on 2015-10-01

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.