Rosanswers logo

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 answers.ros.org, 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 duration in waitforTransform to be 0.001, which could partly solve the problem.

But do you know how to make the execution of getXPose for hector mapping costs time as less as possible?


Originally posted by scopus on ROS Answers with karma: 279 on 2017-07-18

Post score: 0

Original comments

Comment by Procópio on 2017-07-19:
as I understand you are trying to simultaneously map and navigate. have you tried using amcl with a previously built map?

Comment by scopus on 2017-07-19:
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.

Comment by Procópio on 2017-07-19:
Yes, that is the idea. But I was actually wondering if your objective is indeed building a map while navigating?

Comment by scopus on 2017-07-19:
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.

Comment by Procópio on 2017-07-19:
Have you tried hector_navigation?

Comment by scopus on 2017-07-19:
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

Comment by scopus on 2017-07-19:
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.

Comment by FelixMarek on 2017-07-25:
Edit my answer

Comment by FelixMarek on 2017-07-29:
Ok. That makes sense (At least a bit ;-). Apparently TF is to slow. It could be because hector_mapping use at many time also tf transformations. Thereforce tf is to slow. If the planner moves with less waitToTransform also good, you can use this as fix. But actually more wait time is better. +edit


1 Answer 1


Rosanswers logo


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: 0.2
  acceleration_x: 0.1
  acceleration_z: 0.3
  position_accuracy: 0.08
  rotation_accuracy: 0.03
  slow_down_factor: 2.5
  sim_time: 1.5
  local_planner_frequence: 5
  join_obstacle: false


I used ROS indigo and Kinetic. With amcl and without amcl.


Thanks for your measurements @scopus. This log calculation time is coused of to slow tf. Hector_mapping use often tf transformations. So tf is overwhelmed. If the planner moves with hector mapping and less wait time also good, you can use this as fix. But only if you use hector_mapping simultaneously. Because with less wait time it could be that ftc_planner use older positions to calculate the velocity. This can lead to bad/wrong path calculation.

Maybe you can reduce the frequency of the calculation of hector_mapping. But this can lead to bad mapping results.

I consider if i can reduce the Transform calculation.

Originally posted by FelixMarek with karma: 16 on 2017-07-21

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by scopus on 2017-07-25:
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!

Comment by FelixMarek on 2017-07-25:
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)

Comment by FelixMarek on 2017-07-25:
roslaunch rqt_top rqt_top could also be usefull.

Comment by scopus on 2017-07-26:
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

Comment by FelixMarek on 2017-07-27:
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)

Comment by scopus on 2017-07-29:
We updated the question, please read it and give us advices, Thanks!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.