hector_mapping reducing cpu consumption?

Question

Hi I'm using hector_mapping on pandaboard es with arch linux+hydro installed. I have hokuyo urg 04lx. However when i start mapping with default settings. rosrun urg_node urg_node roslaunch hector_mapping mapping_default.launch (Static transform from base_footprint to laser) Nothing else However, when i type "top" to see its cpu usage. It shows nothing below %105.. how can i reduce this. It this normal? Am i doing something wrong? Is it better option for me to use laser_scan_matcher + gmapping

Edit: I installed ros-base from Aur repository using yaourt. After that i cloned hector_slam from from github to my catkin directory and catkin_make only hector_mapping (i installed every dependencies of it)

---

Originally posted by lvntbkdmr on ROS Answers with karma: 23 on 2014-04-09

Post score: 0

Answer 1

To complete @StefanKohlbrecher's answer, the problem is that you built a part of the packages without the proper release flags. Basically, when you use the AUR's PKGBUILDs, the release flag is forwarded to CMake, but if you compile from source with catkin_make, you need to take care of this yourself.

That being said, I just added hector_mapping and its dependencies to the AUR. Remove whatever you installed with catkin_make, install ros-hydro-hector-mapping with yaourt, and you should be just fine. If you encounter any other missing packages in the AUR, please send a package request here, or even better: make a fork, generate the PKGBUILDs yourself, and send me a pull request. Note that generating, compiling, installing and sending to the AUR the missing PKGBUILDs took me less than 5 minutes, so this is definitely worth installing things this way, rather than relying on catkin_make.

---

Originally posted by bchr with karma: 596 on 2014-04-29

This answer was ACCEPTED on the original site

Post score: 1

Answer 2

I haven´t tried things on Pandaboard, so not sure what to expect. That being said, I also noticed that CPU consumption lately was much higher than normal (nearly maxing out a i7 core on our USAR vehicles). As there haven´t been changes to the code in quite some time, I suspect that there might be a problem with one of the used libraries or the build settings. Can you edit your question with information on how you generated the executables (installed from .debs or compiled yourself)?

/edit: There seems to be something wrong with compile flags, see hector_slam issue 11

/edit2: I´d recommend building explicitly in Release mode as suggested in above ticket, just to make sure.

---

Originally posted by Stefan Kohlbrecher with karma: 24361 on 2014-04-09

This answer was NOT ACCEPTED on the original site

Post score: 2

Answer 3

I think it is normal. I run hector_mapping on an Intel PC and I used to see hector_mapping over 100% all the time.

You can adjust the parameters (for me, they're in hector_mapping/mapping_default.launch) to ignore as much of the laser scan as possible. Bump up laser_min_distance. Bump down map_pub_period and laser_max_distance. Maybe there are a few other parameters that have some effect. You can see a list of params on the wiki page. In hector_nav.launch, decrease the map size.

A hacky fix: you can install cpulimit and throttle the CPU usage to whatever you please. I'm using 80% without any noticeable ill effects:

cpulimit -e hector_mapping -l 80

---

Originally posted by AndyZe with karma: 2331 on 2017-05-04

This answer was NOT ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by Stefan Kohlbrecher on 2017-10-12:
This should only happen when you run things on a very weak CPU, otherwise it is very likely that you're compiling with no optimization.

Comment by AndyZe on 2017-10-12:
Thanks. With the parameter changes, CPU load has dropped from ~100% to 30%. Add to CMakeLists instead of typing catkin_make -DCMAKE_BUILD_TYPE=Release:

add_executable(hector_mapping ...)

add_dep...

target_link_lib...

set_target_properties(hector_mapping PROPERTIES DCMAKE_BUILD_TYPE "Release")