what is the best way to follow a moving target?

Question

Hi there!

I am trying to make my robot to follow a moving target, using move_base. However, so far my results are very bad. If I use move_base default global planner, and even if the target moves very little, my robot seems to spend most of the time planning/replanning and pretty much does not move.

I tried to use other global planners as carrot_planner (the robot keeps turning around without following a path) and goal_passer (the robot turns around some times and move_base aborts saying it could not find a path).

Does anyone have any suggestions on how to use move_base to follow a target? The algorithm can be as dumb as it can get, I just need to move along with the target.

Thanks

---

Originally posted by Procópio on ROS Answers with karma: 4402 on 2012-03-02

Post score: 4

Answer 1

move_base is a state-based controller. It has three states of operation: PLANNING, CONTROLLING, and RECOVERY. The problem that you're going to encounter in your application is that every time the target (the object being tracked) moves, move_base will re-enter the planning state, and it cannot drive in that state. It's unlikely that you'll be able to use move_base for this purpose.

It seems that what you're trying to do is similar to a visual servo. You want to publish motor commands that will keep you a certain distance from your target. It doesn't seem to me like this would require much path-planning. It might be solved using simple motor commands (drive forward, turn left, etc) and using the sensor data as feedback.

---

Originally posted by DimitriProsser with karma: 11163 on 2012-03-06

This answer was ACCEPTED on the original site

Post score: 8

---

Original comments

Comment by Pi Robot on 2012-03-06:
@Procópio Silveira Stein If you'd like some sample code to do the kind of visual servoing that @DimitriProsser describes, you might want to check out the TurtleBot follower program. Assuming you have the turtlebot_apps stack installed, just do a 'roscd turtlebot_follower/src' and look at follower.cpp.

Comment by Procópio on 2012-03-06:
thanks for your suggestion @Pi Robot

Answer 2

Hello Procópio!

Hope this late answer can be of some help. We have been confronted to the same issue, and we ended up writing our own local planner.

It is a very simple node subscribing to a moving goal topic. It gets the free space description by subscribing to the local costmap topic. It makes a search of the best (v, w) speed couple within the free space.

An illustration is available here . The somewhat documented CPP code is here .

Hope it can be of any use, Arnaud

---

Originally posted by anonymous2054 with karma: 101 on 2012-03-26

This answer was NOT ACCEPTED on the original site

Post score: 3

---

Original comments

Comment by Procópio on 2012-03-27:
Thanks a lot! I will take a look!

Comment by tgilmour on 2017-06-21:
@arnaudramey Im really interested in the local planner that you wrote but the link no longer works, could you provide a new link to the CPP code you created. Also, Im curious about what package you used to create a local costmap from a laserscan. Thanks very much!

Comment by Procópio on 2017-06-27:
here is a fork of that repo: https://github.com/awesomebytes/hist_user_tracking

Answer 3

As Dimitri said, move_base uses three states PLANNING, CONTROLLING, and CLEARING. In the planning state, move_base invokes the global planner to get a valid plan, and in the controlling state, it passes the global plan to local planners to actuate controllers.

In my opinion there is no reason why the local planner can't use the last valid global plan to continue local motion while the global planner makes new global plan which is already happening continuously in another thread (controlled by planner_frequency). The mutual exclusion of state seems to be a self-imposed constraint.

I had the same problem, and my solution is this one-line hack in move_base.cpp:

//the move_base state machine, handles the control logic for navigation
switch(state_){
  //if we are in a planning state, then we'll attempt to make a plan
  case PLANNING:
    {
      boost::mutex::scoped_lock lock(planner_mutex_);
      runPlanner_ = true;
      planner_cond_.notify_one();
    }
    ROS_DEBUG_NAMED("move_base","Waiting for plan, in the planning state.");
    break;

  //if we're controlling, we'll attempt to find valid velocity commands
  case CONTROLLING:

Remove break;. This let the switch fall through to controlling when it's nominally in the planning state. In the controlling block, it executes according to the last global plan, which is what you need.

I tested this patch with Navfn and Carrot. This is definitely not an elegant solution. It is probably not even correct on the whole. But it works, and might be a good start to properly patch move_base to make the global and local planner truly work in parallel.

Btw, you can reduce the number of goals you send to move_base by thresholding with distance and time from last goal.

---

Originally posted by Lingzhu Xiang with karma: 31 on 2014-05-24

This answer was NOT ACCEPTED on the original site

Post score: 3

---

Original comments

Comment by Procópio on 2014-05-27:
thanks a lot for your input, I will test it right away.

Comment by harmish on 2015-10-22:
hi Procópio, have you already tried this hack? does is work as you needed? we also have similar situation where we would like local-planner to keep executing current plan while the global-planner is calculating the next plan (which can take several seconds in our case).

Comment by Procópio on 2015-10-23:
hi @harmish, sorry but in the end I did not test it.

Comment by TomSon on 2016-04-28:
Have you try teb_local_planner ?

Comment by Procópio on 2016-04-28:
no, I have not. I believe that when I asked this question there was no teb_local_planner.

Comment by lanyaye on 2017-10-20:
hi, @Procópio do you have any update on this? have you tried teb_local_lanner? I'm checking which solution is the best. but from my point of view maybe Arnaud's simple local plan node is best for us. thanks!!

Comment by topkek on 2018-08-26:
how do i get to move_base.cpp? i dont have it in movebase package and when i get it with apt-get source, i dont know how to put it in movebase directory?

Comment by stuggibo on 2019-03-26:
you can download it from github and integrate it into your catkin workspace. Has anyone actually been able to implement it this way? or are there any other packages that allow the robot to follow a moving target, while avoiding obsctacles?