ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Multithreaded RViz?

asked 2014-07-27 14:50:27 -0500

jorge gravatar image

updated 2014-07-28 13:23:08 -0500

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!!!

edit retag flag offensive close merge delete

Comments

1

Are you sure this is related to CPU performance, and not due to poor graphic performance?

ahendrix gravatar image ahendrix  ( 2014-07-27 16:39:11 -0500 )edit

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?

gvdhoorn gravatar image gvdhoorn  ( 2014-07-28 00:56:37 -0500 )edit

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

jorge gravatar image jorge  ( 2014-07-28 02:26:21 -0500 )edit

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"

kmhallen gravatar image kmhallen  ( 2014-07-28 19:58:53 -0500 )edit

Yes, I have no problem passing arguments to gcc. But I don't know how to remove the default ones, e.g. -O2.

jorge gravatar image jorge  ( 2014-07-29 02:08:33 -0500 )edit

When you build in ros, the -O's will be applied by cmake according to the CMAKE_BUILD_TYPE setting.

Daniel Stonier gravatar image Daniel Stonier  ( 2014-07-29 08:44:40 -0500 )edit

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.

Daniel Stonier gravatar image Daniel Stonier  ( 2014-07-29 09:23:35 -0500 )edit

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.

Daniel Stonier gravatar image Daniel Stonier  ( 2014-07-29 09:24:40 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2014-07-29 01:31:07 -0500

gvdhoorn gravatar image

updated 2014-07-29 02:03:34 -0500

After edit: you never mentioned that you were doing things with Octomaps, which is why I assumed (and I think @ahendrix as well) that the performance bottleneck was within any of the subsystems RViz uses, and the performance problems were always there, even when just doing simple path planning with MoveIt.

If performance degrades over time, perhaps you've ran into a memory leak issue. RViz has had some of those in the past (see issues/556 and issues/695 fi). You could use any of the standard tools to catch those.

To get a feeling for which nodes / processes are taking up all the CPU time, try to run rqt_top or just normal top and see what is going on.


Edit: just realised that it could very well be something else (ie: not RViz) that is your performance bottleneck.

edit flag offensive delete link more

Comments

If this really is a memory leak, it's entirely possible that rviz is bottlenecking on memory speed (and not CPU speed) on you desktop vs laptop.

ahendrix gravatar image ahendrix  ( 2014-07-29 01:41:37 -0500 )edit

If something is constantly malloc-ing/new-ing, then yes, I agree. I can see that becoming a problem with pointclouds/octomap usage.

gvdhoorn gravatar image gvdhoorn  ( 2014-07-29 02:02:51 -0500 )edit

OK, my mistake: I shouldn't have mentioned the octomap, as this can blurry the discussion. The performance degradation happens without visualizing octomaps. It just gets worse if I show them, but this means that RViz gets more loaded showing them, not that the CPU struggles creating them.

jorge gravatar image jorge  ( 2014-07-29 02:13:13 -0500 )edit

I'm pretty sure on this because I have monitored the CPU usage of all processes, and the only making heavy use of the CPU is RViz. That said, I have also observed that RViz keeps taking more and more memory after executing a plan, so looks like it has important memory leaks. I will try with valgrind

jorge gravatar image jorge  ( 2014-07-29 02:16:27 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2014-07-27 14:50:27 -0500

Seen: 3,198 times

Last updated: Jul 29 '14