When running Movit on my desktop, RViz cannot show smoothly arm trajectories. Well, it looks cool at the beginning, but after 2 or 3 extra plannings/executions, CPU load reaches 100% and arm trajectories become jumpy.
The point is that my laptop, with a less powerful CPU (same RAM) does a much better job, with RViz taking ~80% of CPU, because in a thread-by-thread basis, is much faster:
- Desktop: AMD FX Series FX-8350 4.0Ghz 8 cores
- Laptop: Intel i7-4600U 3.00 GHz dualcore
So... weird as it can sound, I would love a multi-threaded RViz, or recompile it better fitted for my CPU.
Any idea of what can I do? (I tried overclocking but always make the PC unstable)
Hope this gets useful for ROS users thinking to buy a new PC: carefully check per-thread performance!!!
UPDATE
I made some progresses; compiling RViz for my platform improves things, so now, if I disconnect the 3D sensor, RViz never reaches 100% CPU and so the arm moves smoothly:
set(PLATFORM_FAMILY "amd" CACHE STRING "Platform family, usually referring to intel/arm etc.")
set(PLATFORM_NAME "native" CACHE STRING "Platform name, usually referring to the cpu architecture.")
...
set(PLATFORM_CXX_FLAGS "-march=native" CACHE STRING "Compile flags specific to this platform.")
...
set(CMAKE_BUILD_TYPE Release CACHE STRING "Build mode type.")
However, performance still degrades when RViz shows the octomap (but takes longer). Someone knows any additional compilation tweak to try? Btw, how can I override the predefined compiler flags? It uses -O2, while I want to try -Os instead (I saw in a benchmark assuring it's better for my CPU)
Another solution could be to simplify the arm. Yes, I use the tiny turtlebot arm, but the URDF is surprisingly complex, as it adds a link for every frame element, totaling 25 links! (with 23 meshes). Makes this any sense? Or it will be a waste of time?
Thanks!!!
Originally posted by jorge on ROS Answers with karma: 2284 on 2014-07-27
Post score: 1
Original comments
Comment by ahendrix on 2014-07-27:
Are you sure this is related to CPU performance, and not due to poor graphic performance?
Comment by gvdhoorn on 2014-07-28:
I'm inclined to say the same: on my -- even slower -- machine (2.8Ghz, c2d) -- I can run RViz and MoveIt for hours on end, without it eating up my entire CPU. Could you add some more info on the rest of your hardware?
Comment by jorge on 2014-07-28:
Well, I'm pretty sure it's not the graphic card because I have a one that should be more than enough for RViz (AMD HD 7770), while I have none in the laptop. And even like this, the laptop works better. Also, I changed to proprietary AMD drivers without noticing any improve on RViz
Comment by kmhallen on 2014-07-28:
Any parameter starting with 'D' is passed to cmake.
catkin_make -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-Os
catkin_make -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-Os -march=native"
Comment by jorge on 2014-07-29:
Yes, I have no problem passing arguments to gcc. But I don't know how to remove the default ones, e.g. -O2.
Comment by Daniel Stonier on 2014-07-29:
When you build in ros, the -O's will be applied by cmake according to the CMAKE_BUILD_TYPE setting.
Comment by Daniel Stonier on 2014-07-29:
Run top on the rviz process, use H (threads) and f (fields, select the last used cpu). Are you seeing all the computation in one thread? Mine is, but I'm not testing on anything significant. Being a qt program, I wonder if all the hard yakka is getting done in the main thread.
Comment by Daniel Stonier on 2014-07-29:
Such a large program with alot going on could farm out some jobs to threads or hang widgets on the main one from external threads, but that starts to require some thinking/planning.
Comment by Daniel Stonier on 2014-07-29:
Would starting two instances of rviz with different things showing in each help you multi-core it?
Comment by jorge on 2014-07-29:
One single big glutton thread takes all CPU. As far as I can say, the thread gets 100% of CPU because it process the monitored_planning_scene topic from moveit, that contains really a lot of information. But... I'm new on moveit, so this is just my guess.
Comment by jorge on 2014-07-30:
My college in the office complain that he set CMAKE_BUILD_TYPE as Debug and still have the -O2 optimization option. There's no way to change pre-set options for a compilation type?
Comment by Daniel Stonier on 2014-07-31:
Those -O2 settings are defined as preset configurations by cmake modules that define the compiler you are using (I'm pretty sure). You can override these with: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#variable:CMAKE_USER_MAKE_RULES_OVERRIDE.
Comment by Daniel Stonier on 2014-07-31:
Basically you create a file with something like: set(CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT} ${MY_FLAGS_INIT}") and set CMAKE_USER_MAKE_RULES_OVERRIDE with the filename in your cmake pre-cache.
