What is the relationship between the latest cuRobo and cuMotion?

[DK-feng]

Hi there,

I am familiar with Isaac ROS 3.2. In that version, I used the isaac_ros_cumotion and nvblox packages to perform motion planning with perception. At that time, my understanding was that cuMotion used cuRobo as its backend for trajectory planning and robot segmentation, and there was also a subpackage named curobo_core under the isaac_ros_cumotion folder.

However, I am now confused about the relationship between the latest cuMotion and the latest cuRobo.

From what I see:

1. The latest cuRobo looks more like a standalone Python package and does not appear to be ROS 2-focused.
2. It also seems that the latest cuRobo supports volumetric mapping workflows that overlap with functionality I previously associated with nvblox
3. The latest cuMotion appears to be another independent robotic package that has similar functions related to cuRobo, see: https://github.com/nvidia-isaac/cumotion, and the latest ISAAC ROS cuMotion 4.4 uses this project as its backend rather than cuRobo, see: https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_cumotion/index.html.

So I would like to ask:

• Are the latest cuMotion and cuRobo now completely separate projects, or do they still share some internal relationship?
• If they are separate, which one would you recommend for the best performance and efficiency in robot motion planning with perception?
• If they are still related, could you clarify their current relationship and intended use cases?

Thanks!

[balakumar-s]

Short answer: cuRobo and cuMotion are separate projects, but they are related historically and technically.

cuRobo v2 is the research codebase. It is Python-focused, Apache 2.0, and intended for fast iteration on new motion generation ideas: bi-manual/ humanoid planning, batched trajectory generation, reactive control, depth-fused ESDF, torque-limited planning.

cuMotion is the productized library. It is a separate C++ implementation, with Python bindings, maintained as part of the Isaac ecosystem. It is the right target when you want a hardened, tested motion generation stack.

They do not share a backend today. cuMotion does include optimized and hardened implementations of algorithms that were first introduced in cuRobo, there is technical heritage, but the implementations and codebases are separate.

On the perception side: cuRobo v2 includes GPU-native ESDF functionality for research workflows. In Isaac ROS cuMotion, obstacle-aware planning with perception is integrated through the Isaac ROS stack, including optional nvblox-based 3D reconstruction/SDF generation. So I would not think of cuRobo’s ESDF work as a drop-in replacement for nvblox in Isaac ROS; it is part of the research library.

Recommendation:

• Use cuRobo v2 if you are doing research, prototyping new capabilities, working on high-DoF/humanoid problems, generating training data, or experimenting with the latest algorithms.
• Use cuMotion / Isaac ROS cuMotion if you are building a stack for production or deployment, and the features you need are available there.