Missing camera frame tf transform: fix the frame tree

During a hand-eye calibration or any robot guidance job, a warning such as 'No transform from [camera_color_frame] to [world]' means the tf tree has no connected path between those two frames. Nothing downstream can ask for the camera pose, so the marker appears in the wrong place in the visualization, or the planner refuses to move. This article shows you how to trace the frame tree, find the missing or duplicated link, decide which node must publish each transform, and verify the fix before re-running the calibration. It applies to any camera feeding a vision-guided robot setup, whether the sensor is a depth camera, an area scan camera or a smart camera.

The symptom and what it actually means

The message names two frames, not one error. A tf tree is a set of parent-to-child transforms; a lookup between any two frames succeeds only when a chain of published transforms connects them. The warning tells you that, at the timestamp requested, no such chain existed between the camera frame and the world frame.

Two variants matter:

• The warning appears for every frame of the camera (color, depth, optical): the whole camera subtree is disconnected from the rest of the tree. Look for a missing robot-side transform or a calibration node that never started.
• Only one frame is named: the subtree is attached but one internal link is missing, often the static transform between the driver's color frame and the optical frame.

Note the timestamp too. A lookup that succeeds on the latest data but fails at a specific time points to timing rather than topology.

Step 1: draw the tree you actually have

Do not reason from the launch files alone. Run the frame monitoring tool for ten seconds while the system is running and read its output, or render the tree to an image file and open it. You want two facts on paper:

1. Which frames exist and who is the parent of each.
2. Which frames have no parent at all (isolated roots).

A healthy hand-eye setup looks like this: world to robot base (published by the robot state publisher or driver), robot base through the joint chain to the end effector (published by the robot driver), end effector to camera (published by the calibration result), camera to its optical frame (published by the camera driver as a static transform), and camera to marker (published by the tracking node during calibration). For an eye-on-base rig the camera link hangs off the robot base instead of the end effector.

Step 2: find the break

Compare the drawing with the intended list. The break is almost always one of four cases:

• The calibration node is not running, so the end-effector-to-camera link never appears. The camera subtree stays an isolated island and every lookup to world fails.
• The camera driver publishes no transforms at all, so even the camera-to-optical-frame link is missing. This is common when the driver's frame publishing is disabled in its launch arguments.
• The robot driver publishes joints but no static base transform, so world and robot base never join.
• A frame name typo splits one logical frame into two, for example link_base versus base_link or camera_color_optical_frame versus camera_color_optical. Each typo creates a second isolated root.

Query the specific pair from the warning with the echo tool. The error output names the last connected frame on each side, which is precisely where the tree is cut.

Step 3: fix the missing publisher

For each missing link, decide which node owns it:

• The camera driver owns the sensor frame to optical frame static transforms. Re-enable frame publishing in its launch arguments rather than publishing them yourself.
• The robot driver and robot state publisher own the base and joint chain. Confirm the correct base frame name matches what the calibration launch expects.
• The calibration package owns the end-effector-to-camera transform once calibrated, and during calibration it owns the marker-to-camera tracking branch. Check its namespace: transforms published under a namespace prefix are invisible to nodes looking them up without it.

The same tree discipline applies once you move from calibration to production cells with structured-light and projected-pattern 3D sensors, which publish a sensor frame and a color frame that downstream nodes must reach through the same chain.

Step 4: remove duplicate publishers

The second classic cause is two nodes publishing the same transform with different values. During calibration the warning often appears while the camera marker sits in a wrong orientation in the visualization, which is exactly what a fight over the camera pose looks like.

The usual scenario: the camera driver is included twice, or its frame publishing stays enabled while the calibration setup also supplies transforms for the same frames. List the publishers of the disputed frame with the monitor tool; two entries with different parents is the signature. Disable the driver's own publishing when the calibration configuration is the authority, so exactly one publisher remains per transform.

Step 5: verify before recalibrating

Re-run the checks in order:

1. The tree drawing shows a single connected tree rooted at world.
2. The echo tool resolves the warned pair with no lookup error at the current time.
3. The monitor tool shows one publisher per transform on the camera branch.
4. Move the robot and confirm the camera subtree follows the end effector with no gaps in the timeline; a tree that flickers disconnected during motion means publication rate, not topology, is the problem.

Only then re-run the hand-eye calibration. Once you have a good result, record it so a restart does not lose it, following the camera calibration parameter reuse procedure. If your cell uses two cameras or an external tracking base, the same connectivity rules extend to the shared frame described in the multi-camera shared coordinate frame guide.

For stereo depth sensors such as the binocular structured light camera, verify both the sensor frame and the texture or color frame reach the planning frame; depth and color pipelines can carry separate frame chains from one device.

Choosing the tree design for a new cell

Decide the tree shape before writing launch files:

• Eye in hand: camera frame is a descendant of the end-effector frame. The calibration result fills the last link. See the eye in hand calibration pose selection guide for how many poses the transform needs.
• Eye on base: camera frame hangs from the robot base or from a fixed cell frame, published as one static transform measured during installation.
• Multiple cameras: all camera branches converge on a single shared frame, never on each other.

When your controller consumes the result as a tool or user frame rather than through a transform tree, the arithmetic is the same but the interface differs; the FANUC position transform reference for converting vision world coordinates to a user frame covers that conversion path.

Quick checklist

• Warning names two frames: trace the path between them, not the frames themselves.
• Draw the live tree with the monitor tool; isolated roots mark the break.
• One publisher per transform: check for a camera driver included twice.
• Disable the driver's own publishing only when another node owns those transforms.
• Match frame names character for character across all launch files.
• Verify with the echo tool at the current time and during robot motion before recalibrating.
• Save the calibration result so the link survives a restart.

To plan the hardware side of a guidance cell, start with the 3D sensors category or the camera finder, and the system configurator walks the rest of the chain step by step.