You run rosrun tf tf_echo /camera_link /camera_color_frame between two frames of one depth camera, and the answer prints at once: a 15 mm lateral offset and a near-identity rotation. Then you notice the At time line reads 0.000, and it still reads 0.000 minutes later. The instinct is to suspect the driver, relaunch it, even factory-reset the camera. Nothing is broken. A static transform has no timestamp to show, and the zero is expected. Below: why that is so, two lines of arithmetic that confirm the printed values are sane, and the two-minute tests that separate this normal case from the two faults that resemble it.
The symptom, and what the zero means
On a healthy camera the echo looks like this (example values from a working stereo depth unit; your later decimals will differ):
At time 0.000
- Translation: [0.000, 0.015, 0.000]
- Rotation: in Quaternion [0.001, -0.002, 0.004, 1.000]
in RPY (radian) [0.002, -0.004, 0.008]
in RPY (degree) [0.102, -0.249, 0.432]
Separate the two halves of that output. The translation and rotation are the extrinsic: where the color frame sits relative to camera_link. The At time line is the stamp of that entry, and 0.000 is not "unknown" or "no data". A stamp of zero marks a static entry in tf: valid at every instant, with no measurement time to report.
Time zero also has a second, unrelated job: a lookup requested at time 0 means "give me the latest available", which is why the query itself succeeds. And because the zero comes from how the transform is published, not from the device, restarting or factory-resetting the camera will never move it.
Static versus dynamic transforms in tf
tf is a tree of frames joined by timestamped edges, and its edges come in two kinds. A dynamic edge joins frames that move relative to each other: odometry frame to robot base, robot wrist to tool. The node that owns the motion publishes fresh measurements at its own rate, each stamped with its capture time, and tf interpolates between stamps when you ask for a moment in between.
A static edge joins frames rigidly fixed together. On a depth camera, camera_link, the depth, color and IMU (inertial measurement unit) frames and their optical twins form one rigid assembly, so those extrinsics are measured once, effectively at the factory, and never change. The driver publishes them on the latched static channel: every new listener receives them immediately, the entry carries no measurement time, and no update ever follows, because there is nothing to update. The 15 mm offset in the example is a property of the housing, not of the clock.
The depth-to-IMU edge behaves the same way; the article on verifying the depth camera IMU optical frame transform shows how to check its values. Each sensor also has an optical twin joined to its mechanical frame by one more static edge, and transforming point clouds between the optical frame and the camera frame explains when you want which.
| Static edge | Dynamic edge | |
|---|---|---|
| Frames it joins | One device: link, depth, color, IMU and optical variants | Frames that move: odom to base_link, wrist to camera |
| Publisher | The driver, once, on a latched channel | The node that owns the motion, at its own rate |
| Stored stamp | None, valid at every time | The newest capture time |
| tf_echo prints | At time 0.000, forever | An epoch-seconds value that advances each echo |
| Changes when | The housing changes, practically never | The next measurement arrives |
Confirm the values, not the clock
The zero says nothing about correctness; the numbers do. Check any printed extrinsic with two lines of arithmetic, using the example quaternion [x, y, z, w] = [0.001, -0.002, 0.004, 1.000]:
Norm: sqrt(0.001^2 + 0.002^2 + 0.004^2 + 1.000^2) = sqrt(1.000021) ≈ 1.00001. A unit quaternion to within the tool's three-decimal rounding, so the value is usable as printed.
Angle: sqrt(0.000021) = 0.00458, so theta = 2 × asin(0.00458) = 0.00917 rad, which is 0.53°. The printed RPY agrees: sqrt(0.102^2 + 0.249^2 + 0.432^2) = sqrt(0.2590) = 0.51°. Two prints of the same rotation land within half a degree of identity, so these frames are meant to be aligned, and they are.
Translation: [0.000, 0.015, 0.000] m is 15 mm along +y and nothing else. A color sensor bolted beside the depth module on the same front face produces exactly this shape: a small lateral offset, near-zero offset along the optical axis, near-zero rotation. When the printed values fit the physical camera like that, the extrinsic is correct and you can transform points with it. One thing it does not tell you is which frame variant you transformed into; raw and rectified frames differ, as the depth to color registration guide details.
Two-minute tests
- Re-echo after a few minutes. Same numbers and the same 0.000: confirmed static and healthy. Values that change between echoes mean two publishers are fighting over one child frame, which is the one static-related fault worth chasing.
- Echo a pair that truly moves. On a cell with odometry or a robot, echo odom to base_link: the At time value should be an advancing epoch-seconds number. That proves the tf system stamps and serves time normally, isolating the zero to the static edge, where it belongs. A camera alone on a bench publishes only its static device frames, so skip this test there.
- Read the driver's start-up log. Look for a line saying a transform for a child frame is being ignored. That message means a second static publisher tried to give an already-parented child a different transform, and the buffer keeps the first and drops the rest. The cause is almost always a duplicate driver instance or a leftover hand-written static publisher.
- Check the frame tree when a lookup fails. A wrong or unpublished frame name gives a lookup error, never 0.000 with sensible values. If tf_echo cannot resolve a frame at all, the frame is missing from the tree, which is a different problem with its own fix in missing camera frame tf transform: fix the frame tree.
When 0.000 does point at a real fault
Two cases hide behind the same zero.
Conflicting static publishers. Symptom: 0.000 plus values that contradict the housing, say a 100 mm offset between frames that share one face, together with the ignored-transform line in the log. Two nodes published static transforms for the same child, and tf kept whichever arrived first. Fix: run one driver instance, delete any hand-written publisher that repeats device extrinsics, relaunch once and re-echo.
A moving camera that nobody publishes. If the camera rides a robot wrist, the device frames still print 0.000, correctly, but the wrist-to-camera edge is yours to publish. A missing publisher shows up as a lookup failure, not as a stale time. For a bolted, eye-to-hand mount, one static transform holding your calibrated values is the right shape, and publish eye-to-hand calibration as a static camera transform walks through it.
The fix, case by case
- 0.000, values fit the mechanics: take no action. The extrinsic is correct and resolves at any timestamp you request, because a static entry never expires.
- Your node needs a stamped transform: stamp your output message when you build it. Asking for the extrinsic at the point cloud's own capture stamp succeeds without interpolation, since a static entry serves every time.
- Ignored-transform line, or implausible values: remove the duplicate static publisher or the second driver instance, relaunch, re-echo, and compare the numbers against the housing.
- Camera on a moving mount: calibrate and publish the mount edge yourself, and leave the device-internal edges exactly as the driver publishes them.
Prevention
Four habits keep this corner quiet:
- Let the driver own the device-internal extrinsics; never re-publish a device frame from your own node.
- Keep exactly one static publisher per child frame, and check the start-up log whenever you add a node to the launch.
- Run the norm-and-angle check on every hand-entered transform; it catches typos at once. A w entered as 0.990 instead of 1.000 gives theta = 2 × acos(0.990) ≈ 0.28 rad ≈ 16°, a rotation no rigid mount should carry.
- Re-echo an edge after physically moving a mount: a static value never drifts on its own, but a moved bracket invalidates it.
At time 0.000 is what a healthy static transform prints. Verify the values once with the arithmetic above, keep the publishers unique, and get on with the inspection. If the next open question is the camera hardware itself, depth technology, range or mounting, start at the 3D sensors category or the camera finder. More frame and capture fixes sit on the 3D vision topic page, and contact is the route if you want an integration looked at before you order.
Questions
What does tf_echo print for a transform that actually moves?
An epoch-seconds value that advances on every echo, for example 1718000000.0 on a wall-clock system. tf_echo requests the latest transform and prints the stamp of the newest measurement in the chain. If the pair you echo is joined by a static transform you will see 0.000 instead, because a static entry carries no measurement time. A moving pair that prints 0.000 means its publisher is not stamping: that publisher, not the camera, is the thing to check.
The depth-to-IMU transform also shows At time 0.000. Is that the same cause?
Yes. The IMU frames sit in the same housing as the depth and color frames, so that extrinsic is static too and rides the same latched channel with stamp 0. The IMU data itself is different: accelerometer and gyro messages carry their own per-sample timestamps at their sample rate. Frames carry geometry; streams carry time. If the IMU topics publish with sensible stamps, the 0.000 in tf_echo needs no fix.
Should the camera-to-robot transform also be static?
If the camera is bolted in the cell looking at a fixed workspace, yes: publish base to camera once as a static transform with your calibrated values, just as the driver publishes its device extrinsics. A wrist-mounted camera is rigid to the flange, so that edge can be static too; the motion is already captured by the robot's own frames. Re-publish only after you physically move or recalibrate the mount.
Does tf_echo query the camera itself?
No. tf_echo reads only the tf buffer: it asks for the transform between two frame names and prints what the buffer holds. It never talks to the device, so the 0.000 says something about how the transform was published, not about camera health. That is also why a restart or factory reset cannot change it, and why an absent camera gives a lookup error rather than a stale time.
Why does each sensor have a plain frame and an optical frame?
Each sensor gets two: the mechanical frame that matches the housing axes, and the optical twin that follows the image convention with z pointing into the scene. One fixed rotation, published static, joins them, so echoing between the pair also prints 0.000. Use the mechanical frame to place the camera in space and the optical frame to transform pixels; mixing them swaps points between axes.