Ask Your Question
0

Odom position below map, navigation problem

asked 2017-06-19 06:11:02 -0600

dottant gravatar image

updated 2017-06-19 06:57:55 -0600

Hi all
I'm implementing the simulation for a robot which has to move within an environment composed by a ground floor (which will be not used) and a first floor.
The mapping task seems to be ok, the robot can map the first floor with good accuracy.
The navigation task has to be performed at the first floor and has problems: first thing, which I don't know if it's an error, the robot odom frame seems to be under the spawned map and robot. image description
The main problem is that the local costmap seems to not mark the possible obstacles, the local costmap remains light gray as you can see in the picture about the frames if i set to "/odom" the global_frame in the local_costmap_param, so the path planner doesnt work as it should be, instead if i set to "/map" the global_frame in the local_costmap_param it seems to mark the obstacles and walls, but anyway a lot of times it fails to avoid them and to reach a goal because the path is really closed to the wall or obstacles.
These are my param files
base_local_planner.yaml

   TrajectoryPlannerROS:
  #Set the velocity limits of the robot
  max_vel_x: 0.4
  min_vel_x: -0.2 #0.1
  max_vel_theta: 0.2
  min_vel_theta: -0.2
  min_in_place_vel_theta: 0.2
  #The velocity the robot will command when trying to escape from a stuck situation
  escape_vel: -0.2
  #Set the acceleration limits of the robot
  acc_lim_theta: 0.1
  acc_lim_x: 0.1
  acc_lim_y: 0.1
  #Set the tolerance on achieving a goal
  latch_xy_goal_tolerance: false
  xy_goal_tolerance: 0.1
  #Is it holonomic?
  holonomic_robot: false
  #How long and with what granularity it'll forward simulate trajectories
  sim_time: 1.7
  sim_granularity: 0.025
  angular_sim_granularity: 0.025
  vx_samples: 8
  vtheta_samples: 20
  #Parameters for scoring trajectories
  path_distance_bias: 0.8      # 1.0   - weighting for how much it should stick to the global path plan
  goal_distance_bias: 0.8      # 0.8   - wighting for how much it should attempt to reach its goal
  gdist_scale: 0.8
  pdist_scale: 1.0
  occdist_scale: 0.5           # 0.01   - weighting for how much the controller should avoid obstacles
  heading_lookahead: 0.325

  dwa: false
  meter_scoring: true

  #How far the robot must travel before oscillation flags are reset
  oscillation_reset_dist: 0.05
  #Eat up the plan as the robot moves along it
  prune_plan: false
  #Global Frame id
  global_frame_id: map`


costmap_common_param.yaml

footprint: [[0.39, 0.30], [0.39, -0.30], [-0.30, -0.30], [-0.30, 0.30]] #FRIDAY
footprint_padding: 0.0
transform_tolerance : 0.5
map_type: voxel


##OBSTACLE LAYER##
obstacle_layer:
  enabled: true
  obstacle_range: 2.5
  raytrace_range: 3.0
  #expected_update_rate: 0.0
  #observation_persistence: 0.0
  #min_obstacle_height: 0.0
  max_obstacle_height: 1.0
  publish_voxel_map: false
  origin_z: 0.0
  z_voxels: 2
  z_resolution: 0.2
  unknown_threshold:    15
  mark_threshold:       0
  combination_method:   1
  track_unknown_space:  true  #true needed for disabling global path planning through unknown space
  observation_sources:  laser_scan_sensor #cliff_sensors
  laser_scan_sensor:
    data_type: LaserScan
    topic: /friday/laser/scan
    marking: true
    clearing: true
  #cloud_scan_sensor 
  #laser_scan_sensor
  #sonar_scan_sensor
  #sonar_scan_sensor: {sensor_frame: sonar_1, data_type: LaserScan, topic: /sonar_scan, marking: true, clearing: true, expected_update_rate: 100.0, min_obstacle_height: 0.1, max_obstacle_height: 0 ...
(more)
edit retag flag offensive close merge delete

Comments

Hi, I'm encountering the same strange problem since friday. Have you found a solution? Could it depend on the value of odometrySource in the differential drive plugin?

sva gravatar imagesva ( 2017-06-20 12:06:25 -0600 )edit

Can you add a single tf value for your odom and map transforms? e.g. "rosrun tf tf_echo /base_footprint /odom" and "rosrun tf tf_echo /base_footprint /map"

Humpelstilzchen gravatar imageHumpelstilzchen ( 2017-06-21 00:59:05 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2017-06-21 03:15:36 -0600

dottant gravatar image

Thanks about the answers, but I've found the solution.
It depends on the tag odometrySource of the differential_drive_controller plugin for my robot model in Gazebo, which must be set on encoder. Previously I set it to world, that's why the odom was below the map frame.
Now everything is ok and I can set the param global_frame to "/odom" in the local_costmap_params file.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2017-06-19 06:11:02 -0600

Seen: 155 times

Last updated: Jun 21 '17