Skip to main content
Version: 10

Performance Troubleshooting

MoveIt Pro Example Workspace Camera Streams are laggy​

Problem: When I run a MoveIt Pro example robot config, such as lab_sim, I see that the camera streams in the UI visualizer are choppy or unperformant.

Solution: Close other graphics-heavy applications, update the graphics drivers on the desktop-app computer, and restart the MoveIt Pro desktop app. Also confirm that the computer meets the system requirements.

tip

For NVIDIA GPU users, please see our NVIDIA setup guide to enable GPU Acceleration inside the MoveIt Pro docker container

Problem: Even with hardware acceleration enabled, things still don't look smooth for the camera streams in an example robot config.

Solution: You can remove the camera streams to improve performance in MoveIt Pro if your computer is unable to handle it by:

  1. edit lab_sim/description/scene.xml and comment or remove the camera block lines
  2. edit lab_sim/description/picknik_ur.xacro and change the render_publish_rate to 0:
<param name="render_publish_rate">0</param>

MoveIt Pro build takes a long time or hangs, locking up my CPU​

Problem: When I moveit_pro build a large workspace, my computer starts to lock up.

Solution: There are three possible solutions that can help improve the build performance of a large workspace:

One) (Recommended) On your host, enable RAM compression. This uses more CPU cycles, but that is generally what gets you into trouble with dev computers these days - the RAM can't keep up with the CPU. You can setup a larger swap file with zram.

sudo apt-get install zram-config

If the first solution doesn't work for you:

Two) Reduce the number of threads (the number following -j) cmake instructs the compiler to use:

export MAKEFLAGS=-j1
moveit_pro build

Three) Reduce the number of parallel packages built at a time:

moveit_pro build user_workspace --colcon-args "--parallel-workers 1"
tip

If you know the greedy package(s), you can get really fancy and chain commands together to only slow down the build during that package:

moveit_pro build user_workspace --colcon-args "--packages-up-to GREEDY_PACKAGE" &&
export MAKEFLAGS=-j1 &&
moveit_pro build user_workspace --colcon-args "--packages-select GREEDY_PACKAGE" &&
export MAKEFLAGS=-j$(nproc) &&
moveit_pro build user_workspace

MoveIt Pro is killed during a long Objective involving multiple MTC pipelines​

Problem: While running a long Objective that plans many MoveIt Task Constructor (MTC) tasks, the MoveIt Pro Runtime suddenly stops and the logs show the planning process was killed:

[objective_server_node_main-6]: process has died ... exit code -9

Solution: Exit code -9 means the process was sent SIGKILL, which during heavy planning is usually an out-of-memory kill. To confirm, run sudo dmesg on the host and look for a line containing Killed process. While the Objective runs, you can also watch docker stats: container memory climbs in large steps each time an MTC planning Behavior executes.

By default, each MTC task keeps everything it evaluated, including the candidate solutions and the planning scene captured with each one, so you can inspect the results in the Task Constructor Debugger. From MoveIt Pro 10.2, only the most recently planned MTC tasks keep that data (10 by default, configurable with mtc_introspection_retained_tasks in the objectives section of config.yaml). Retained memory still scales with that limit times the per-task footprint — a detailed collision model can put hundreds of megabytes in each task — so if this kill happens on 10.2 or later, lowering the limit is the first remedy. On earlier versions, an Objective that plans many tasks holds all of that at once, how much each task holds grows with the detail of your collision model, and memory staying high after the Objective finishes is expected: each task's planning data is kept for inspection until the next Objective is loaded.

See Keep Memory Bounded in Large Objectives for ways to bound memory further.