If LiDAR frames begin jumping only after a second navigation stack or robot starts, audit transform ownership before tuning localization. Two processes may publish the same child frame, or two robots may use identical embedded frame IDs in a shared transform domain. Different node names do not necessarily create different frame identities.
Capture the system with each stack alone and then with both running. For every important edge, identify the intended parent, child, publisher and physical robot. Compare the received transforms and their sources, not only a frame-tree drawing. The goal is to establish one coherent ownership plan for each consumer’s transform domain.
This procedure addresses competing authorities and identity collisions. It does not assume that every jump is a duplicate publisher: global localization corrections, clock resets and sensor errors can produce other discontinuities. Record the ROS distribution, package versions, launch arguments and remappings. Development references below must be compared with the deployed release.
Start with the roles of map, odom and base
REP 105 distinguishes a continuous local odometry frame from a global map frame that may change discretely. A map correction can therefore be intentional. First identify which relationship jumps and whether the behavior conflicts with that edge’s intended role. Do not use visual smoothness as the only correctness criterion.
Draw the expected chain for each robot, including the sensor’s rigid mounting edge. List the component intended to supply each relationship. A common arrangement can involve a localization component, a local odometry producer and a model publisher, but the actual owners depend on the platform. Treat the drawing as an integration contract to verify, not a generic launch template.
Keep measurement provenance distinct from transform ownership. Two estimators may use related observations without publishing the same transform, or may publish competing transforms despite consuming different sensors. The duplicate odometry input audit addresses the first question. This workflow asks which process has authority to publish each coordinate relationship.
Capture one stack, then the combined system
Begin from a documented clean startup and record the publishers visible to the affected consumer. Save both dynamic and static transform traffic, relevant node information, launch configuration and diagnostic output. Keep the robots stationary initially so a changing physical pose cannot obscure a disagreement between publishers.
Repeat with the second stack isolated, then with both enabled under the same observation method. Record when the extra publisher appears and whether a child frame acquires a different parent, translation or rotation. A short recording around startup is often more informative than a screenshot taken after the system has settled.
The TransformStamped definition includes the reference frame in the header and the child frame in a separate field. Inspect those strings in the actual messages. Topic names and namespaces are not substitutes for checking the identities inside the payload.
Retain the received values together with publisher evidence available from the deployed middleware and diagnostic tools. A tree visualization can summarize topology while hiding alternating values or multiple sources. If the tooling does not expose authority clearly, use controlled isolation to establish which process contributes each edge instead of guessing from its name.
Separate namespaces from frame identity
Inventory node namespaces, topic names and embedded frame IDs in separate worksheet columns. Namespacing a node or remapping a transform topic need not rewrite the frame strings in its messages. Verify the actual outcome for every driver, estimator and bridge rather than assuming one launch-level prefix changes all publishers consistently.
The robot_state_publisher reference documents a frame_prefix option and distinguishes fixed-joint publication on tf_static from movable-joint publication on tf. That option belongs to this component. Other producers must be configured consistently; it does not automatically rename frames emitted by a LiDAR driver or another estimator.
Choose a coherent design for the intended transform domain. Systems can use distinct frame identities in a shared domain or deliberately isolated transform traffic with appropriately configured consumers. Document how any shared world relationship is introduced. Do not partially combine designs and expect a consumer to infer which similarly named base frame belongs to which robot.
Check bridges and republishers in the same inventory. They may merge traffic, preserve old frame strings or apply their own prefixes. Compare the payload before and after the boundary. Preserve existing production configuration while testing a candidate design in an isolated environment, with a rollback record for every planned change.
Audit the usual overlapping publishers
Check whether the base driver and an estimator both publish the local odometry-to-base relationship. The robot_localization state-estimation reference describes world-frame modes and transform publication. Inspect the effective configuration of each estimator instance, rather than assuming a second instance is only a passive consumer.
Check fixed sensor mounts in the robot model against manually launched static publishers. A second static publisher can repeat or contradict an edge already represented by the model. The official static broadcaster implementation exposes explicit parent and child choices. Verify the installed interface and every launch instance before using another broadcaster as a repair.
Also check localization and mapping stacks that both expect to own map-to-odom. A robot can legitimately run multiple components, but their published relationships must follow the selected architecture. Do not disable an owner solely because its process started later; first establish which component the downstream navigation system is intended to trust.
Build an ownership worksheet
| Relationship | Document | Verify |
|---|---|---|
| Global map to local odometry | Selected localization or mapping owner | No unintended competing authority |
| Local odometry to robot base | Driver or estimator ownership decision | Publication settings of all candidates |
| Base to fixed LiDAR | Model joint or explicit static owner | No conflicting manual duplicate |
| Robot-specific identities | Frame strings and traffic domain | Agreement across drivers and consumers |
| Bridge boundary | Forwarding and prefix behavior | Actual outgoing frame IDs and sources |
Distinguish an ownership collision from missing transform history. If an edge has one correct owner but is unavailable at a sensor timestamp, use the TF time-coverage diagnostic. The clock-check guide addresses time-domain differences. Repeatedly adding broadcasters will not resolve either problem.
After a supported ownership correction, rehearse isolated and combined startup again. Include a component restart and late consumer connection where relevant to the deployed design. Compare the same stationary scene and retain dynamic values as well as topology. A clean first startup alone does not demonstrate that recovery preserves the ownership contract.
Include recorded-data playback in the publisher inventory when it is used during diagnosis. A bag containing transform topics can reintroduce an old owner into a live system even when the current launch files appear correct. Keep replay inputs isolated and document which topics are forwarded. Compare the graph seen by the affected consumer, rather than only the processes on the robot computer; a remote workstation or bridge can contribute an additional source.
Common integration questions
Will unique node names solve duplicate frame IDs?
Not necessarily. Inspect the frame strings carried in messages and the transform domain consumed by the application. Node identity and coordinate-frame identity serve different purposes.
Should every transform use a static publisher?
No. Static publication describes a relationship that is fixed by design. It must not be used to conceal a changing odometry or localization relationship, or to override an existing owner without architectural evidence.
What makes a useful review request?
Provide one-stack and combined recordings, the ownership worksheet and effective configurations. The support bundle guide packages that evidence. The restart recovery checklist helps test whether the corrected identities and owners remain consistent after component recovery.
