Why is the TF tree structure in Isaac Sim different from standard ROS 2? Do I have to follow Isaac Sim's structure?

Omniverse Isaac Sim
1

Hi all,

I’m currently working on integrating a robot simulation in Isaac Sim with ROS 2 (Humble), and I’ve noticed a discrepancy in the TF tree structure.

In ROS 2, the typical TF tree looks like this:

<world/map/odom> → base_footprint → base_link → [sensors, etc.]

But in Isaac Sim, the default TF tree generated is:

→ base_link → base_footprint → [sensors, etc.]

This seems to reverse the relationship between base_link and base_footprint.

I understand that base_footprint is usually a 2D planar frame used by the navigation stack, while base_link represents the robot’s actual 3D pose (with roll/pitch/yaw). However, in Isaac Sim, base_link is often the articulation root, which may be why it’s placed at the top of the tree.

My questions are:

  1. Why does Isaac Sim use this structure?
  2. Is there a technical reason I must follow Isaac Sim’s TF structure?
  3. Can I safely change the articulation root to base_footprint in Isaac Sim without affecting the simulation or physics?
  4. What’s the best practice if I want to align the TF tree with the standard ROS 2 navigation stack?

Thanks in advance!

4

Hi @Jackie3075 welcome to the community and thanks for bringing this issue to our attention. Let me reach out to our internal team about your concerns.

5

Hi @Jackie3075 there is no particular reason for Isaac Sim to use this structure. Actually you can change base_footprint to come before base_link. It’s just a semantic choice. There are cases in ROS community where base_link comes before base_footprint as well.

As long as base_footprint is part of the Articulation you can designate any part of the articulation to come before other prims of the articulation.

In terms of TF structure. Isaac Sim should give base_link → sensors/links or base_footprint → sensors/links.

odom → base_link/base_footprint is provided by either ground truth odometry (provided by Isaac Sim) or it will come from a odometry estimator (from ROS stack).

map → odom comes from a localization node that is part of the ROS stack (If you want perfect localization you can just provide a static TF of the initial pose of the robot as the transform between map and odom).