Ask Your Question

The new path planner(ftc_local_planner) can't work with hector_mapping together

asked 2017-07-18 22:11:56 -0600

scopus gravatar image

updated 2017-07-28 19:33:11 -0600

Hi, all, this question is similiar to the question we have asked here. But we found new situations, so we change the subject and ask a new question here.

We are using hector mapping and move_base to implement an online mapping and path planning. We changed the combination of global planner and local planner.

If the global planner is "navfn/NavfnROS", the local planner is dwa_local_planner, the robot moves fine and builds the map, although the terminal outputs following warning.

[ WARN] [1500425881.365911556, 793.010000000]: Control loop missed its desired rate of 4.0000Hz... the loop actually took 0.5200 seconds

[ INFO] [1500425881.365978957, 793.010000000]: Got new plan

[ WARN] [1500425881.784682569, 793.430000000]: Control loop missed its desired rate of 4.0000Hz... the loop actually took 0.4200 seconds

Then if the local planner is "ftc_local_planner/FTCPlanner", the global planner is navfn or other methods (We tested a linear global planner programmed by us). The robot almost doesn't move(only with rotation in place sometimes), and the following warning outputs. We also decreased the update frequency of costmap and the control frequency, but it didn't work.

[ WARN] [1500431832.147879220, 6740.630000000]: Map update loop missed its desired rate of 1.0000Hz... the loop actually took 21.1200 seconds
[ WARN] [1500431854.738732473, 6763.210000000]: Control loop missed its desired rate of 4.0000Hz... the loop actually took 22.5800 seconds
[ WARN] [1500431854.738900263, 6763.210000000]: Map update loop missed its desired rate of 1.0000Hz... the loop actually took 21.5800 seconds

We also tried other slam package like karto. The robot works fine.

So it seems that the combination of hector mapping with ftc_local_planner can't work together, we wonder why the robot can't translate when the mapping method is hector and the local planner is ftc_local_planner.

Can anyone who is familiar with move_base give us advices?



For experiments in simulator(gazebo), the hardware is with Intel® Core™ i5-6500 CPU @ 3.20GHz × 4 , memory is 15.6 GiB. We thinks such hardware is totally enough for running hector and ftc_local_planner. So it is so weird that the above warning information is output. As I am told from some questions in , this is usually because the CPU power or memory is not enough for running such packages.


Hi,@FelixMarek. Thank you for your advices! After by adding the time calculation into the source code in sereral different places. We found that the most time-consumed part is the function getXPose in transform_global_plan.cpp. When running with hector mapping, It takes about 0.10 seconds for obtainning the transform between the goal_pose and global_frame. Since getXpose is often called by other functions, so the accumulative time is so much that blocks the execution.

However, when running with other mapping pacakges such as gmapping, karto, It takes almost no time (actually 0.0000 seconds) to obtain the transform between the goal_pose and global _frame. Do you know why? We can change the ... (more)

edit retag flag offensive close merge delete


as I understand you are trying to simultaneously map and navigate. have you tried using amcl with a previously built map?

Procópio gravatar image Procópio  ( 2017-07-19 01:41:16 -0600 )edit

Thank you! We didn't use amcl with a previously built map. In this case, a map server is enough. How the map is built is not important. So the mapping packages don't need to be launched.

scopus gravatar image scopus  ( 2017-07-19 01:50:44 -0600 )edit

Yes, that is the idea. But I was actually wondering if your objective is indeed building a map while navigating?

Procópio gravatar image Procópio  ( 2017-07-19 01:55:15 -0600 )edit

Our objective is not only building a map. The robot also have to finish other tasks such as cleaning room(with coverage path planning) like cleaner vacuum robot. So the tasks and map building are running at the same time. We also obtain the robot's pose from map building to guide the path planning.

scopus gravatar image scopus  ( 2017-07-19 02:04:52 -0600 )edit

Have you tried hector_navigation?

Procópio gravatar image Procópio  ( 2017-07-19 08:02:25 -0600 )edit

No. Actually we also considerd hector_move_base_navigation which uses their own move_base node. But we think even if we run them successfully, we can't use the specified planner, our problem is not solved either

scopus gravatar image scopus  ( 2017-07-19 22:57:11 -0600 )edit

We think the key to solve this problem is: how to modify the move_base(or the planner) or hector mapping to make them work together successfully.

scopus gravatar image scopus  ( 2017-07-19 23:01:03 -0600 )edit

Edit my answer

FelixMarek gravatar image FelixMarek  ( 2017-07-25 06:04:11 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2017-07-21 07:30:06 -0600

FelixMarek gravatar image

updated 2017-07-31 06:51:17 -0600


Thanks for your measurements @scopus. This log calculation time is occurs of to slow tf. Hector_mapping and ftc_planner use often tf transformations. So tf is overwhelmed. I have minimized the calls of tf transformations and put this changes for the moment in an new branch "fix_transformation". If I have test the changes in detail I will merge it to the master branch.

Old conversation

This could coused because the ftc_planner need to much time to calculate. Can you show your ftc_planner paramaters?

And how big is your global map with your are build (Resolution)?

Drives your robot fine, if you use ftc_planner on a already created global map (without hector mapping)?


I cant reconstruct this problem. If I use the same parameter the planner works fine with hector mapping.

I have add a Debug output in the ftc_planner. Now you should see how long the plan calculation is. Mostly it should lover than 0.0005 seconds It is shown the calculation time in seconds.

The calculation time of the ftc_planner is only dependet on the global plan lenght and its resolution. So what is your global planner?

You can also activate the debug output at the hector map (in the launch file) to see the calculation time of it.


My Output with same parameters and navfn in gazebo simulation:

[DEBUG] [1501069889.603913517, 2303.245000000]: Planning...
[DEBUG] [1501069889.606579979, 2303.245000000]: Got Plan with 65 points!
[DEBUG] [1501069889.606638318, 2303.245000000]: Generated a plan from the base_global_planner
[DEBUG] [1501069889.606699296, 2303.245000000]: Planner thread is suspending
[DEBUG] [1501069889.883098172, 2303.514000000]: Publishing feedback for goal, id: /move_base-1-2287.511000000, stamp: 2287.51
[DEBUG] [1501069889.883148549, 2303.514000000]: Publishing feedback for goal with id: /move_base-1-2287.511000000 and stamp: 2287.51
[DEBUG] [1501069889.883180475, 2303.514000000]: Got a new plan...swap pointers
[DEBUG] [1501069889.883201015, 2303.514000000]: pointers swapped!
[DEBUG] [1501069889.883239073, 2303.514000000]: FTCPlanner: Old Goal == new Goal.
[DEBUG] [1501069889.883253688, 2303.514000000]: In controlling state.
[DEBUG] [1501069889.883484852, 2303.515000000]: FTCPlanner: max_point: 37, distance: 0.256672, x_vel: 0.233333, rot_vel: 0.022912, angle: 0.017184
[ INFO] [1501069889.883600382, 2303.515000000]: FTCPlanner: Calculation time: 0.001000 seconds
[DEBUG] [1501069889.883617439, 2303.515000000]: Got a valid command from the local planner: 0.233, 0.000, 0.023
[DEBUG] [1501069889.883634019, 2303.515000000]: Full control cycle time: 0.000611030

The calculation of the path is very simple (you can look in die driveForward Methode at the code). There is no couse because the calculation is so long.

But i have also used some times the turtlebot, and there is very slow in calculation because many background processes. But my turtlebot wasnt so slow.


I have install the turtlebot packages and drives the turlebot in simulation. The calculation isnt so high like yours >0.01 seconds. I have run: Gazebo, RVIZ, Turtlebot amcl_demo.launch (with ftc_local_planner) and hector_mapping. I have deactivate "pub_map_odom_transform" at hector_mapping. And I have nicer parameters for FTCPlanner:

  max_x_vel: 0.2
  max_rotation_vel: 2.0
  min_rotation_vel ...
edit flag offensive delete link more


Out global planner is here. We tested it mostly in simulated environment by gazebo . If we change this global planner to be navFn, the problem still exists. Thanks!

scopus gravatar image scopus  ( 2017-07-25 07:01:16 -0600 )edit

ok. I have no plan why it doesnt work with hector. For my personal interest can you check the Debug output of ftc_planner (the new git push before an hour), and how big the calculcation time is? (Enable Debug output with roslaunch rqt_logger_level rqt_logger_level)

FelixMarek gravatar image FelixMarek  ( 2017-07-25 08:07:07 -0600 )edit

roslaunch rqt_top rqt_top could also be usefull.

FelixMarek gravatar image FelixMarek  ( 2017-07-25 08:22:05 -0600 )edit

Thanks! You mentioned the amcl_demo.launch. Did you do your experiments with a known map built by hector mapping in advance? We didn't use amcl. We launched hector mapping and movebase at the same time. It's a navigation with online mapping. The robot's pose is obtained from mapping, not from amcl

scopus gravatar image scopus  ( 2017-07-26 16:57:34 -0600 )edit

Because I cant reconstruct this problem. If you want use ftc_planner you must show where the calculation problem is. Thereforce add duration debug outputs in the driveToward in ftc_planner.cpp. Or you must use dwa_planner with hector (But with personal experience dwa drives very worse)

FelixMarek gravatar image FelixMarek  ( 2017-07-27 08:44:40 -0600 )edit

We updated the question, please read it and give us advices, Thanks!

scopus gravatar image scopus  ( 2017-07-29 16:08:03 -0600 )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: 2017-07-18 22:11:56 -0600

Seen: 995 times

Last updated: Jul 31 '17