ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

navfn stability

asked 2013-02-06 20:40:07 -0500

Peter Listov gravatar image

updated 2013-02-08 04:07:41 -0500

dornhege gravatar image

I encountered with the problem that global_planner in navfn package makes invalid plans. It means that they go through walls on a map like on this picture. image description

There is ROS Electric on board.
Cannot find out why it happens, so I'd appreciate any suggestions.

UPD. I tried with original navigation stack (as well as with forked base_local_planner and move_base) and it still makes plans through the walls sometimes. Is it possible that it's a bug in navfn package? Is there any others global planners?
Here are my configs:
1. base_local_planner_params

    controller_frequency: 5.0
  max_vel_x: 0.70
  min_vel_x: 0.1
  max_rotational_vel: 1.5
  min_in_place_rotational_vel: 1.0
  acc_lim_th: 0.75
  acc_lim_x: 0.50
  acc_lim_y: 0.35

  holonomic_robot: false
  yaw_goal_tolerance: 1.1
  xy_goal_tolerance: 0.15
  goal_distance_bias: 0.8
  path_distance_bias: 0.6
  sim_time: 1.5
  heading_lookahead: 0.325
  oscillation_reset_dist: 0.05

  vx_samples: 6
  vtheta_samples: 20
  dwa: false

2. costmap_common_params

obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[-0.35, -0.245], [0.35,-0.245], [0.35,0.245], [-0.35, 0.245]]
footprint_padding: 0.01
inflation_radius: 1.0
observation_sources: filter
filter: {data_type: LaserScan, topic: /filter, marking: true, clearing: true}

3 global_costmap_params

   global_frame: /map
   robot_base_frame: /base_link
   update_frequency: 3.0
   publish_frequency: 0.0
   static_map: true
   transform_tolerance: 0.5

4 local_costmap_params

   global_frame: /odom
   robot_base_frame: /base_link
   update_frequency: 5.0
   publish_frequency: 5.0
   static_map: false
   rolling_window: true
   width: 4.0
   height: 4.0
   resolution: 0.1
   transform_tolerance: 0.5


5 BaseLocalPlanner.cfg

# gen.add("inscribed_radius", double_t, 0, "The radius of the inscribed circle of the robot", 1, 0)
# gen.add("circumscribed_radius", double_t, 0, "The radius of the circumscribed circle of the robot", 1, 0)

gen.add("acc_lim_x", double_t, 0, "The acceleration limit of the robot in the x direction", 1.0, 0, 20.0)
gen.add("acc_lim_y", double_t, 0, "The acceleration limit of the robot in the y direction", 1.0, 0, 20.0)
gen.add("acc_lim_theta", double_t, 0, "The acceleration limit of the robot in the theta direction", 1.0, 0, 20.0)

gen.add("max_vel_x", double_t, 0, "The maximum x velocity for the robot in m/s", 0.55, 0, 20.0)
gen.add("min_vel_x", double_t, 0, "The minimum x velocity for the robot in m/s", 0.0, 0, 20.0)

gen.add("max_vel_theta", double_t, 0, "The absolute value of the maximum rotational velocity for the robot in rad/s",  1.0, 0, 20.0)
gen.add("min_vel_theta", double_t, 0, "The absolute value of the minimum rotational velocity for the robot in rad/s", -1.0, 0, 20.0)
gen.add("min_in_place_vel_theta", double_t, 0, "The absolute value of the minimum in-place rotational velocity the controller will explore", 0.4, 0, 20.0)

gen.add("sim_time", double_t, 0, "The amount of time to roll trajectories out for in seconds", 3, 0, 10)
gen.add("sim_granularity", double_t, 0, "The granularity with which to check for collisions along each trajectory in meters", 0.025, 0, 5)

gen.add("pdist_scale", double_t, 0, "The weight for the path distance part of the cost function ...
edit retag flag offensive close merge delete


This should never happen and I've never seen it happen. I suspect it's probably more of a setup issue. Could you add your configuration?

dornhege gravatar image dornhege  ( 2013-02-07 03:10:10 -0500 )edit

Can't see anything obviously wrong, besides maybe the publish_frequency of 0.0. I can't look it up right now as is down. One other thing: Your rviz display seem not to correspond to each other at all. Can you explain that? Maybe something is wrong with tf/frames?

dornhege gravatar image dornhege  ( 2013-02-08 00:21:02 -0500 )edit

Sorry, did not get what is not corresponded? And one more clarification. As far as I understood navfn algorithm works standalone and my base_local_planner hacks will not affect global_planner. For example I've changed the weights for local trajectories.

Peter Listov gravatar image Peter Listov  ( 2013-02-08 01:14:24 -0500 )edit

The pink cells you display are the plan, etc. right? It doesn't seem to match anything (the map, the current robot pose). That seems odd. Yes, you understood this correctly. Changing things in the local planner is irrelevant for the global planner.

dornhege gravatar image dornhege  ( 2013-02-08 01:30:09 -0500 )edit

Yes, the pink cells are inflated obstacles. The green one are lethal_ostacles recognized by kinect. The red are laser scans. I think that they are dismatched with the static map a little because of errors in the navigation system.

Peter Listov gravatar image Peter Listov  ( 2013-02-08 02:00:42 -0500 )edit

OK, so this might only be for the local planner. What is the green plan then? Is that maybe from the local planner? This would explain everything. Given the obstacles you display the green plan is correct. Unfortunately this local planner isn't bound to the global plan and makes its own decisions.

dornhege gravatar image dornhege  ( 2013-02-08 02:33:06 -0500 )edit

If it doesn't consider the map the observations are consistent. Can you check which plan you display? Usually there are three different topics.

dornhege gravatar image dornhege  ( 2013-02-08 02:34:23 -0500 )edit

The green plan is the global plan computed by navfn. One interesting thing: the first plan is always correct. This problem popped up when I tried cope with oscillations of my robot. So I hacked move_base a little to remake the global plan once a minute.

Peter Listov gravatar image Peter Listov  ( 2013-02-08 02:48:29 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2013-03-12 13:13:02 -0500

tfoote gravatar image

It looks like your range sensor possibly has seen through the wall. In that case the map will be updated to reflect that there's no obstacles seen in that location and it's valid to plan there.

edit flag offensive delete link more


And in this case navfn disregards the static map?

Peter Listov gravatar image Peter Listov  ( 2013-03-18 03:29:39 -0500 )edit

Yes. Problematic as it may be, the costmap will overwrite the static map to trust its local sensors (just in case there's noise in the map)

David Lu gravatar image David Lu  ( 2013-03-20 12:00:45 -0500 )edit

Same happened to us, not sure whether tullys explanation holds: In any case setting /move_base_node/planner_frequency to non-zero can help reduce the problem. hydro seems to be okay for us, with stage anyway.

KruseT gravatar image KruseT  ( 2013-08-02 04:17:14 -0500 )edit

In the updated hydro nav, the static map is NOT overwritten. It should probably be configurable, but I haven't made that edit yet.

David Lu gravatar image David Lu  ( 2013-08-02 07:43:21 -0500 )edit

Your Answer

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

Add Answer

Question Tools



Asked: 2013-02-06 20:40:07 -0500

Seen: 1,148 times

Last updated: Mar 12 '13