planner frequency delays replanning on new goal

[tkruse]

When setting the /move_base_node param to a low frequency above 0, e.g. 0.5, then this frequency delays replanning even when a new goal is set, which IMO it shouldn't.

To reproduce:
start navigation in stage:
$ roslaunch navigation_stage move_base_fake_localization_10cm.launch

set the param dynamically:
$ rosrun dynamic_reconfigure dynparam set /move_base_node planner_frequency 0.05

In rviz, set a nav goal, with mouse, robot should start moving towards goal.
Set another nav goal while robot is moving, and robot will stop moving,and global planning will be delayed by 0 to 20 secs.

I believe move_base should, upon receiving a new goal, immediately replan globally.

[hershwg]

I agree, perfectly reasonable request.

Looks like this is caused by the r.sleep() call on line 623 of move_base.cpp. To fix, the loop needs to be reworked somehow so that the single (potentially big) call to r.sleep() is broken up into multiple short sleeps, with checks for new plan requests (or actionlib goal pre-emptions?) in between.

I don't have time to look into this right now, but the change should be feasible without affecting any APIs or other files I think.

[mikeferguson]

should be fixed by #282