cuMotion MoveIt Plugin with Isaac Sim: Missing controller_manager and planning scene services on Jetson Thor

I attempted the Tutorial for cuMotion MoveIt Plugin with Isaac Sim example on the Jetson Thor platform.
I first launched Isaac Sim on my x86 machine, then navigated to
Window > Examples > Robotics Examples > ROS2 > MOVEIT, and opened FrankaMoveIt.

RViz was successfully launched using the command franka_isaac_sim.launch.py, and the robot model was loaded correctly. However, it was never able to connect to the service /controller_manager/list_controllers.
Meanwhile, the cuMotion planner node terminated after 30 seconds because it was waiting for the service /publish_static_planning_scene, which never became available.

Here is the log from running franka_isaac_sim.launch.py,
here is the log from running cumotion_planner_node,
here is the topics of ros2 topic list,
here is the services of ros2 service list,
and here is a video showing my operation.

It appears that some configuration is missing in order for the system to run correctly. I would appreciate your assistance.

Hello @shentunghuang1,

The package cuMotion is currently not working due to changes in the upstream MoveIt. We are actively working on a fix. Please be patient, and we will keep you updated as soon as the fix is released.

I take it didn’t get updated yet in isaac ros 4.1 too, right?
In Isaac Manipulation examples with cuMotion the planning always fails.
In cuMotion examples with moveit I get this output:

admin@localhost:/workspaces/isaac_ros-dev$ ros2 launch isaac_ros_cumotion isaac_ros_cumotion.launch.py cumotion_planner.robot:=$(ros2 pkg prefix --share isaac_ros_cumotion_robot_description)/xrdf/franka.xrdf cumotion_planner.urdf_path:=$(ros2 pkg prefix --share moveit_resources_panda_description)/urdf/panda.urdf
[INFO] [launch]: All log files can be found below /home/admin/.ros/log/2026-02-06-21-12-15-344639-localhost.localdomain-22255
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [static_planning_scene-1]: process started with pid [22258]
[INFO] [cumotion_goal_set_planner_node-2]: process started with pid [22259]
[static_planning_scene-1] [INFO] [1770408738.690227585] [static_planning_scene_server]: Static Planning Scene Server initialized
[cumotion_goal_set_planner_node-2] [INFO] [1770408739.341503510] [cumotion_planner]: Loading grid position and dims from grid_center_m and grid_size_m parameters.
[cumotion_goal_set_planner_node-2] [INFO] [1770408741.305888903] [cumotion_planner]: warming up cuMotion, wait until ready
[cumotion_goal_set_planner_node-2] [INFO] [1770408747.126182237] [cumotion_planner]: cuMotion is ready for planning queries!
[static_planning_scene-1] [INFO] [1770408747.127655430] [static_planning_scene_server]: No static planning scene file path provided
[cumotion_goal_set_planner_node-2] [WARN] [1770408747.184780867] [cumotion_planner]: Static planning scene service failed: No static planning scene file path provided

cuMotion package should already be updated for Isaac ROS 4.1.
The log you saw is just a warning and is harmless as long as the workflows run. It appears because the static_planning_scene_server has no static scene file configured, so when cuMotion asks it to load a static planning scene, the service returns an error that’s reported as that warning. Planning should still proceed, and you should see the planning result messages after that line.

Hi @vchuang, thank you for the reply.

Quick update from my side: even in 4.1 I was still unable to plan with cuMotion.

Tracking down the issue I noticed a timing issue: MoveIt reports planning success before cuMotion finishes producing the trajectory. I was consistently getting this problem in both isaac_ros_cumotion_examples (Franka tutorial) and Isaac Sim manipulator workflows.

I created a patch in my fork of isaac_ros_cumotion and now it seems to work. In Python action servers I moved goal_handle.succeed() to the end of the callback, after the result and trajectory are fully prepared. In the MoveIt C++ client I removed the send_goal_options_.result_callback path and reset plan_response for each request.

With these changes the Success -> No trajectory behavior disappeared and planning/execution now behaves as expected.