The Isaac Compute Odometry Node causes position drift (especially, large z drift)

Note: For any Isaac Lab topics, please submit your topic to its GitHub repo ( GitHub - isaac-sim/IsaacLab: Unified framework for robot learning built on NVIDIA Isaac Sim ) following the instructions provided on Isaac Lab’s Contributing Guidelines ( Contribution Guidelines — Isaac Lab Documentation ).

Please provide all relevant details below before submitting your post. This will help the community provide more accurate and timely assistance. After submitting, you can check the appropriate boxes. Remember, you can always edit your post later to include additional information if needed.

Isaac Sim Version

[ V ] 5.0.0
[ V ] 4.5.0

4.2.0
4.1.0
4.0.0
4.5.0
2023.1.1
2023.1.0-hotfix.1
Other (please specify):

Operating System

[ V ] Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):

GPU Information

  • Model: I am using the RTX 3060, RTX4070, and RTX5090 models.
  • Driver Version: 570 and 580 (Tested Ubuntu Drivers in Ubuntu Repository)

Topic Description

Odometry drift issue in Isaac Compute Odometry Node

Detailed Description

I am using the Isaac Compute Odometry Node in Isaac Sim to publish odometry (odom) and TF transforms. When I set the robot’s /base_link as chassisPrim, the robot moves correctly on the ground plane, but the computed odometry shows error in the overall position coordinates. (The z-axis drift is particularly noticeable.)

Expected behavior:
The robot should move on the ground plane without drift, and the odometry should match the robot’s actual movement and align with the base_link transform.

Actual behavior:
The odometry output shows instantaneous error, especially noticeable in the z-axis, and also deviates in x and y. The larger the position change, the greater the error. In other words, the transform of body_link in Isaac Sim does not match the outputs in the Action Graph (i.e., the published odometry message).

The robot traveled 123 m, and the x and y axes showed negligible error, roughly 0.001 m, but the z-axis exhibited an error of 0.24 m.

Its transform is published by the ‘Publish Transform’ node in the Action Graph. It matches the base_link transform shown in Isaac Sim’s Stage, and the z position remains around zero (with small fluctuations of about 0.0001–0.0002 depending on the orientation).

At first, I thought the issue was caused by either incorrectly setting the parent prim or by the link’s orientation being tilted, which would result in the pose being computed relative to the wrong parent prim. However, neither the orientation nor the position was misconfigured (both were initialized to (0,0,0)). When I checked the TF output using Publish Transform Tree, I confirmed that it shows the correct pose without any drift.

This issue might be intentional, but I believe that for roboticists it would be important to have an Action Graph node that provides the exact pose, velocity, and orientation from the simulation at each computation step — or at least an odometry output where the error does not accumulate with position.

Steps to Reproduce

  1. Create an Isaac Compute Odometry Node in the Action Graph.

  2. Set the chassisPrim to /base_link (or another movable link in the robot).

  3. Move the robot forward about 100 m on a flat ground plane.

  4. Observe the odometry.

(Add more steps as needed)

Error Messages

(If applicable, copy and paste any error messages you received)

Screenshots or Videos

(If applicable, add screenshots or links to videos that demonstrate the issue)

Additional Information

What I’ve Tried

(Describe any troubleshooting steps you’ve already taken)

Related Issues

(If you’re aware of any related issues or forum posts, please link them here)

Additional Context

The Isaac Compute Odometry Node calculates the linear and angular twist. From this, we can see that the linear velocity along the z-axis and the angular velocity around the x and y axes are correctly reported as zero.

For reference, the robot being used is a 2D-kinematic based mobile robot.

If anyone has encountered a similar issue or knows how to resolve it, I would greatly appreciate any guidance.

Hey @Kryptos_sim I would like to try to replicate this issue on my side. Could you please share your files? Or can I replicate this issue with any robot in the isaac asset, for example, nova carter robot?

Hello, thank you for your reply.

Yes, this issue can be replicated with the Nova Carter robot.

You can reproduce the problem with a simple setup: create a Ground Plane under the World prim, place the Nova Carter robot on it, and then use the Action Graph to publish the odom and TF topics. This should be enough to observe the same odometry drift I described.

If you have any trouble replicating it, please let me know. I’d be happy to share my files.

@Kryptos_sim I tested with the carter_warehouse_navigation example in Isaac Sim 5.0.0. I manually drag the robot around (I cannot do the whole recording as the forum only allow maximum 100MB file). On the right side, it is the position.z value of the /chassis/odom data. I don’t observe any drifts. Have you tried this example?

Thank you for sharing the video. I’ve watched it carefully.
As you mentioned, when simply dragging or moving the top-level prim manually, I also do not observe this issue.

However, in my case, I’m moving the robot using /cmd_vel messages (not by directly manipulating the prim). Within a few meters of movement, the odometry remains accurate, but when the robot travels over a long distance (tens of meters or more), noticeable drift occurs, especially along the z-axis.

It doesn’t seem to depend on the robot type — I tested both my own robot model and the one currently being used by @zhengwang, and the issue appears in both cases.

After comparing the outputs, I found that the Isaac Compute Odometry Node and the Publish Transform Node produce slightly different results — only the z-axis value differs. The odometry node seems to compute it inaccurately.

I’m not sure why this happens, but conceptually, when a robot moves on a flat ground plane, the z-axis position should remain fixed around zero (apart from very small fluctuations as seen in your video).

Apologies for my late response — I’ve been busy recently. I’ll try to provide additional data, such as the relevant files or a short video demonstrating the issue, as soon as possible.