Planning with non-optimized end-effector Joints

[Alems8]

Description
I am integrating cuMotion in a manipulation stack (UR + Robotiq gripper) and I ran into a structural limitation regarding how cuMotion builds its internal joint state.
Currently, cuMotion filters the incoming sensor_msgs/JointState to only the joints defined in the XRDF C-space (optimization joint list). As a consequence, any joints not included in C-space are effectively ignored at planning time. This creates an issue for gripper-aware planning.

Problem Statement
In many manipulation scenarios the gripper joint(s) should not be optimization variables (i.e., we do not want to plan a time-parameterized trajectory for them); however, their current position must be reflected in collision checking. e.g. if the gripper is open, the planner should consider the wider collision geometry. Currently, if the gripper joint (e.g., finger_joint) is not part of the C-space, cuMotion does not use its current value from /joint_states. Collision geometry reflects a default value instead of the real opening
If the gripper joint is added to C-space it becomes an optimization DoF and returned trajectories include the gripper joint. This forces downstream execution to support multi-controller trajectory splitting
In many real systems, grippers are executed via GripperCommand actions rather than FollowJointTrajectory, so this complicates execution significantly

Expected Behavior

It would be very useful if cuMotion supported the following model:

• C-space defines optimization joints
• Non-C-space joints are treated as locked/passive joints
• Their values are populated from the latest JointState
• These locked joints are included in forward kinematics and collision checking
• But they are not optimized and do not appear in the output trajectory
  In other words: all joints in the robot model should influence collision checking, but only C-space joints should be optimized and returned in the trajectory.

Why This Matters

This allows:

• Gripper-aware planning without making the gripper an optimization DoF

• Cleaner execution pipelines (no need for trajectory splitting or multiple controllers unless explicitly desired)

• Better modularity when swapping grippers (only joint state publication changes)
  - This is especially important for manipulation stacks where:
  - The arm is controlled via FollowJointTrajectory
  - The gripper is controlled via GripperCommand

• Planning and execution layers are intentionally decoupled

Questions

• Is this filtering behavior intentional by design?
• Is there currently a supported way to keep a joint out of C-space but still have its value influence collision checking?
• Would you consider supporting “locked joints from JointState” as a first-class concept in cuMotion?