ROS2 odometry / TF marker is offset from rendered CubeSat point cloud in Isaac Sim 5.1

Omniverse Isaac Sim
1

Hi, I’m working on a CubeSat manipulation simulation in Isaac Sim 5.1 with ROS 2 Jazzy and MoveIt, and I’m having trouble getting the simulated CubeSat pose from odometry/TF to line up with the object seen by a depth camera.

My setup is:

  • Isaac Sim 5.1

  • ROS 2 Jazzy

  • xArm7 with a gripper-mounted depth camera

  • A free-floating CubeSat target, approximately 0.10 m × 0.10 m × 0.35 m

  • ROS2 Camera Helper publishing /gripper_camera/points

  • ROS2 Odometry Graph publishing /cubesat/odom

  • A custom ROS 2 node publishing an RViz Marker box from odometry/TF

In RViz I currently display:

  • Raw point cloud from /gripper_camera/points

  • A green bounding box from my PCL detector

  • A blue bounding box representing the CubeSat pose from odometry/TF

The green PCL box is expected to be imperfect because visible thruster exhaust cone geometry is also being picked up by the point cloud. My real issue is the blue odometry box: it is consistently offset from the actual visible CubeSat body points.

The blue tracker is now odometry-only and does not subscribe to the perception pose anymore. It initializes its absolute pose from World -> Cube and applies motion from /cubesat/odom.

Here is what I get:

ros2 run tf2_ros tf2_echo World Cube


Translation: [0.025, 0.239, 1.623]
Rotation: [0.000, 0.000, 0.000, 1.000]

And the blue tracked pose is essentially identical:

ros2 topic echo /cubesat/tracked_pose --once


pose:
  position:
    x: 0.0251939
    y: 0.2386031
    z: 1.6228983
  orientation:
    x: 0.0
    y: 0.0
    z: 0.0
    w: 1.0

The detected point-cloud pose is elsewhere:

pose:
  position:
    x: 0.0252156
    y: 0.1632750
    z: 1.4195547

I understand that the perception pose is not a reliable ground-truth pose because it includes the exhaust cone geometry. However, when I inspect the raw point cloud visually, the blue marker still does not appear centered on the actual CubeSat body.

For odometry, I created an ROS2 Odometry Graph with the CubeSat prim assigned as the object being tracked. /cubesat/odom is publishing correctly:

header:
  frame_id: odom
child_frame_id: Cube
pose:
  pose:
    position:
      x: 0.0
      y: 0.0
      z: 0.0
    orientation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0

The zero pose is expected because the satellite is stationary after starting playback.

My questions are:

  1. For a free-floating rigid object that is not a robot, what is the correct way to configure the ROS2 Odometry Graph in Isaac Sim?

  2. Does the tracked CubeSat prim need a dedicated centered child Xform or rigid-body reference prim for TF/odometry, even though it is just an object to be picked up by MoveIt?

  3. Is the odometry chassis/root prim origin what determines the pose published to ROS, and if so, how should I verify or correct that origin relative to the rendered CubeSat body?

  4. Would it be better to publish a dedicated centered transform for the CubeSat body and use odometry only for velocity/motion data?

  5. Is there a recommended way to keep visible thruster exhaust geometry in the scene while making sure it does not affect the body pose reference used for odometry and MoveIt collision objects?

I do not need the green PCL bounding box to perfectly match the rigid body right now. I mainly want the blue marker to represent the actual simulated CubeSat body pose reliably so that I can eventually update the MoveIt collision object from it.

I can provide the stage hierarchy, the Odometry Graph settings, or more RViz screenshots if that would help.

image
image222×275 645 Bytes

3

Hi,
The TF/odometry pose is z = 1.623, the point-cloud centroid is z = 1.420 — a ~0.20 m gap, which is just over half your CubeSat’s 0.35 m long axis. So, it looks like your prim origin isn’t at the body’s geometric center: odometry is reporting the origin (at one end of the body), while the cloud centers on the visible body.

This is by design — the Isaac Compute Odometry node uses the chassis prim’s origin as the reference point, not the mesh centroid. So the marker is correct for the origin you gave it; the origin just doesn’t sit where you expect.

To your questions:

  1. Config for a free-floating object is the same as a robot: assign the CubeSat’s rigid-body prim as the Chassis Prim. Note the published pose is relative to its pose at playback start (the odom frame), which is why /cubesat/odom reads zero while stationary — that’s expected.
  2. Yes — add a centered child Xform. Create a child Xform sitting at the true geometric center of the body and track that (or move the mesh so its local origin coincides with the Xform origin). This is the cleanest fix.
  3. Yes, the chassis/root prim origin determines the published pose. Verify it by selecting the CubeSat prim in the stage — the move gizmo shows the origin/pivot. If it sits at a corner or end rather than mid-body, that’s your offset. Correct it by zeroing the mesh’s local translation relative to a centered Xform.
  4. A dedicated centered transform is a good approach. Publish a static transform to a centered body frame and let odometry provide motion/velocity — this decouples “where the body center is” from “the rigid-body root.”
  5. Isolate the exhaust geometry. Put the thruster/exhaust meshes under a separate child that’s excluded from the rigid body’s collision and mass, and define your body-center frame on the main body only. Build the MoveIt collision object from that centered frame rather than the perception cloud.

In short: re-center the tracked prim’s origin (or add a centered child Xform) and the blue marker will line up with the body.

4

Hello!

We noticed that this topic hasn’t received any recent updates from anyone reporting this issue, so we are closing it for now to help keep the forum organized.

If you are still experiencing this issue or have related questions, please create a GitHub Discussion or Issue in the Isaac Sim repository and include a link to this topic along with updated details. Mentioning or linking to this original topic provides helpful context and makes it easier for others to assist you.

Thank you for being part of the NVIDIA Isaac Sim community.

Best regards,
The NVIDIA Isaac Sim Forum Team