Frame transform name matching issue

[thomassedlmayer]

As far as I understand the features of Lichtblick, it is currently not possible to overlay data coming from different topics in the 3D panel if the naming of frame transforms does not match.

Apparently, attaching scene entities to the "scene graph" of the 3D panel is completely dependent on the "unique" naming of frame transforms.

E.g. if certain scene entities are attached to frame transform "xyz" and other scene entities (e.g. from another topic) are attached to frame transform "abc", it is not possible to somehow connect these even if "xyz" and "abc" are logically at the same position (e.g. a certain fixed reference point at a car).

The other way round, frame transforms with the same name (but used by different topics) are handled the same, even if they potentially aren't exactly the same.

Also see lichtblick-suite/asam-osi-converter#92 by @Yaccoub

Proposals

1. It should be possible to create additional custom transforms from the Lichtblick GUI and manipulate their parent transform by typing the corresponding transform name (see screenshot). This would enable creating potentially missing frame transform names and attach those to any desired frame transform.
   

2. It should not be assumed that frame transforms with the same name are handled the same for all topics by default. E.g. the "root" of one topic could differ from the "root" of another topic even if they're both called "root".

@Yaccoub @jdsika Please feel free to complement/adjust my problem description and proposals if I missed something.

[aneuwald-ctw]

Hey @thomassedlmayer,

Thanks for bringing this up — very good points.

Just to clarify, the correct and recommended approach for handling this kind of situation — both in Lichtblick and in ROS in general — is through FrameTransform messages.

If you have logically equivalent frames with different names (like ego_vehicle_rear_axle vs ego_vehicle_rear_axis), or need to establish relationships between frames (like introducing an odometry frame between <root> and your vehicle frames), this should be done via publishing proper FrameTransform messages. This is the default mechanism designed for precisely this use case.

Using FrameTransform, you can define how each frame relates to others in a consistent and dynamic way, and Lichtblick will render everything accordingly in the 3D panel. That way, frames that should align will align, and frames that should remain separate will remain so — based on the transform tree.

Regarding adding this mapping capability directly in the UI: while it could be useful as a convenience feature in the future (especially when dealing with data sources that can't be modified), it is not the preferred approach right now. Ideally, transforms should come from the data itself, and Lichtblick will rely on that to resolve positioning and hierarchy correctly.

Does this make sense and address your case?
If so, I’d suggest trying to solve it via FrameTransform first and letting us know if that works for you — or feel free to reach out if there are any blockers or if something is still unclear.

Thanks again for raising this!

[aneuwald-ctw]

By the way, you can use for now this link for reference about the FrameTransform: https://docs.foxglove.dev/docs/visualization/message-schemas/frame-transform

[thomassedlmayer]

@aneuwald-ctw Thanks for the quick reply!

If you have logically equivalent frames with different names (like ego_vehicle_rear_axle vs ego_vehicle_rear_axis), or need to establish relationships between frames (like introducing an odometry frame between and your vehicle frames), this should be done via publishing proper FrameTransform messages. This is the default mechanism designed for precisely this use case.

The issue I see is that at the time of data creation you may not know what frame names the extensions expect. This requires an extra step of regenerating the data with the corresponding frame transforms in order to be compatible with a set of extensions (requiring the person/tool that creates data to know about the internals of the involved extensions). Also, if an extension for some reason changes frame transform names, you would have to readjust your data to adapt to that change.

And still, frames with identical names can not be handled differently because of a lack of namespace scoping, right? This seems like a major problem if Lichtblick aims to encourage working with different independent data sources and extensions. You can't really tackle this issue by publishing additional frame transforms if I understand that correctly.

Ideally, transforms should come from the data itself, and Lichtblick will rely on that to resolve positioning and hierarchy correctly.

From a long-term architecture perspective, wouldn't it be preferable to decouple frame transform naming/handling from the data, at least for visualization purposes? This seems like a nightmare for debugging and inspecting "old" data or data that you did not generate by yourself and know nothing about.

Does this make sense and address your case?
If so, I’d suggest trying to solve it via FrameTransform first and letting us know if that works for you — or feel free to reach out if there are any blockers or if something is still unclear.

I'd hand this question over to @Yaccoub since he is the one who experienced the issue first-hand. He might be able to tell you if this is a acceptable solution.

[aneuwald-ctw]

Hey @thomassedlmayer,

Totally fair concerns — thanks for expanding.

That said, what you're describing is actually by design in both ROS and Lichtblick. A frame_id is meant to uniquely identify a coordinate frame — and the transform tree is built based on those names being consistent and unambiguous. So yes, having two different transforms with the same name but different meaning is not something the system is built to support, and we don’t plan to introduce scoped or namespaced frame IDs. That would break assumptions at multiple layers of the visualization and transform systems.

Regarding data generation: you don't need to modify the original data source. You can use a custom extension (or converter) to inject the necessary FrameTransform messages and adapt frame names or hierarchies however you need. Extensions already support that pattern well, and you can even expose this behavior via Settings API for user-level configuration.

So while we totally understand the idea of making the system more flexible from the UI, our position is that this should still be solved structurally via transforms — it's the most robust and future-proof solution. For cases where data isn't modifiable, extensions remain the right level of abstraction for this.

Let us know if this helps, or feel free to challenge anything here — always happy to iterate.