Publish eye-to-hand calibration as a static camera transform

A fixed camera can be calibrated correctly yet remain disconnected from the runtime coordinate-frame tree. This usually happens when the publisher loads the wrong file, selects the moving-camera mode, or attaches the calibrated frame beneath the wrong parent. This procedure is for integrating an existing eye-to-hand calibration into an operating vision application. You will identify the saved transform, configure its publisher, and verify the resulting frame relationship before enabling any motion that depends on it.

1. Define the fixed relationship and its owner

1. Write down the robot reference frame, the calibrated camera frame, and the component responsible for publishing their relationship.

For eye-to-hand operation, the camera remains fixed relative to the robot base or another stationary reference. Its calibration therefore belongs on a fixed branch of the frame tree, not beneath the moving tool.

A typical arrangement is:

robot_base
  camera_link
    camera_optical_frame

The camera driver may already provide the relationship between its mechanical frame and optical frame. Your calibration publisher should connect that existing camera subtree to the robot reference without adding a second parent to any frame.

A static transform is appropriate only while both reference frames remain mechanically fixed. If the camera moves relative to the base, this relationship is no longer constant.

Before changing publishers, use the missing camera frame diagnostic procedure to distinguish a missing connection from a naming or lookup problem.

The same integration method applies across suitable area scan cameras and vision controllers. Hardware selection does not determine transform direction. For example, the LS-CMR-0053 can be reviewed during camera planning; confirm acquisition-software compatibility separately.

The MV-VC2140-128G40-1T is another hardware reference for system planning. Verify operating-system, driver, and application requirements before selecting a processing platform.

2. Select fixed-camera mode and the saved result

2. Configure the installed calibration publisher for a fixed camera, and select the intended saved calibration explicitly.

You generally do not need to rewrite launch-file conditionals when the launch interface already supports both mounting arrangements. Select its fixed-camera mode instead. For an interface exposing the following argument names, use this configuration intent, subject to the installed release's documentation:

Do not assume that every software release interprets an empty file argument identically. Where an explicit file path is supported, it makes startup behavior easier to audit. Confirm the resolved path in startup logs rather than relying on the launch configuration alone.

Inspect the selected file before launching. Record its mounting mode, frame identifiers, translation units, rotation representation, and calibration revision. Confirm that the runtime publisher can read it under its actual service account.

A configuration namespace and a coordinate-frame name serve different purposes. Changing a namespace does not necessarily rename frames, and selecting a new namespace may change where a publisher searches for its saved result.

If the camera, lens, mounting arrangement, or robot reference has changed, follow the calibration recovery procedure before publishing an old result.

3. Match the parent and child to the calibrated frames

3. Identify the exact coordinate systems represented by the saved transform, then choose the runtime edge that preserves those meanings.

The parent should be the stationary robot reference represented by the calibration. The child should be the camera-side frame whose pose that calibration actually describes, unless you explicitly compose another known transform.

Names such as camera_link and camera_optical_frame are not interchangeable labels. They may have different origins and axis directions. Similarly, a robot's world, base, mounting, and user frames can represent different coordinate systems.

A frame-name override is appropriate when correcting a name mismatch for the same physical coordinate system. It is not a substitute for transforming between different origins or orientations.

Suppose calibration describes the optical frame, but the driver already publishes the mechanical-to-optical relationship. Adding a second base-to-optical edge would conflict with that existing parent. Instead, derive the base-to-mechanical relationship:

Here, A_T_B means the pose of frame B expressed in frame A. Transform multiplication follows the written order; it is not commutative.

Inspect the driver's actual frame relationships before applying this composition. Do not insert an assumed optical-axis rotation when the driver already supplies it. The optical-frame point-cloud transform explanation covers why these frame distinctions matter for measured coordinates.

4. Confirm transform direction with a numerical example

4. Establish what the saved matrix maps before setting an inversion option.

For a parent named robot_base and a child named camera_frame, the published transform represents the camera frame's pose in the robot base frame. It maps camera-frame coordinates into base-frame coordinates:

A filename containing both frame names does not establish the direction. Check the calibration export convention and publisher documentation, then verify the mapping using a known point or independently measured pose.

Consider an illustrative transform with a 90-degree rotation about the base Z axis and this camera-origin position:

This is an integration example, not a calibration result or acceptance tolerance. It demonstrates both rotation and translation, making direction mistakes easier to detect than an identity-transform example.

If the saved result maps base coordinates into camera coordinates, invert the entire rigid transform:

For the example above, the inverse translation is (0.2, 0.4, -0.8) m. Simply negating the original translation would be wrong because the rotation also changes its coordinate basis.

When rotations are stored as quaternions, check component order and normalization. An (x, y, z, w) interface is not interchangeable with a (w, x, y, z) file representation. Also verify whether any angle-based interface expects radians or degrees.

The camera-to-base verification procedure addresses calibration validity beyond this publication-direction check.

5. Publish the edge from one authoritative source

5. Start one publisher for the chosen edge and remove competing ownership before accepting the runtime tree.

Possible owners include a calibration publisher, a robot-description fixed joint, a camera integration launch file, or a separate static-transform process. Choose one. Do not leave an old publisher active while adding a replacement with the same child frame.

Check both static and dynamic transform sources. A calibration edge published statically can still conflict with another process publishing that child dynamically. Likewise, publishing the inverse as a second edge can introduce a cycle rather than provide a useful additional lookup.

For a supported static-transform mechanism, use that mechanism rather than repeatedly broadcasting an unchanged transform merely to keep it visible. Confirm that a listener started after publication still receives the fixed relationship.

Record publisher ownership alongside the calibration revision. A useful deployment record includes:

• Parent and child frame identifiers.
• Calibration file location and revision or checksum.
• Direction represented by the saved result.
• Any fixed-frame composition applied before publication.
• Launch configuration responsible for the edge.

After replacing a calibration, restart the relevant publisher and verify the result from a fresh listener. Existing listeners may retain previously received static data. Check that no old process remains available to reintroduce it.

6. Verify the runtime result before using it

6. Verify connectivity, numerical agreement, and physical meaning as separate checks.

First, inspect the runtime tree. The camera must connect to the intended robot reference through a single, unambiguous path. Confirm exact spelling, capitalization, and any applied frame prefix.

Next, query the transform in the same target and source order your application uses. For a camera point expressed in the base frame, the target is the base and the source is the camera. Compare the returned pose with the selected calibration, allowing for any documented intermediate-frame composition.

Then perform a physical plausibility check:

• Does the translation place the camera near its measured mounting location?
• Do the displayed camera axes point in the expected directions?
• Does a known point transform to the expected side of the robot base?
• Do several reference points agree across the working region, rather than only near its center?

Set acceptance limits from the application error budget. For example, translation agreement within 0.001 m means agreement within 1 mm; it does not establish that the original calibration is accurate to that value.

A static edge also does not repair timing errors elsewhere in the system. A point measured from a moving object still requires compatible acquisition times and any necessary dynamic transforms.

Once publication is verified, use the robot-base pick computation procedure to apply the relationship to detections. A connected tree alone is not sufficient evidence for enabling automatic motion.

7. Recognize when a static camera edge is the wrong fix

7. Stop and resolve the underlying model when the proposed edge does not represent a fixed rigid relationship.

A planar pixel-to-table calibration is not automatically a complete spatial camera pose. A homography may support a particular working plane without providing the rigid transform required by a three-dimensional frame tree. Review the planar guidance selection guide when the available result is a two-dimensional mapping.

Similarly, do not attach an eye-to-hand result beneath the tool merely because another example uses that layout. That would make a stationary camera appear to move with the robot.

If the camera is mounted on a moving slide, use the documented kinematic relationship and measured slide state. If multiple cameras need a common reference, manage their separate extrinsics rather than giving them the same frame identifier. The shared-frame multi-camera calibration guide covers that arrangement.

Finally, a corrected publisher cannot compensate for a physically shifted camera or an incorrect calibration target model. Revisit calibration when independent reference checks remain wrong after publication matches the saved result.

8. Complete the commissioning checklist

Before accepting the integration, confirm each item:

• Fixed-camera mode selected: runtime configuration matches the physical mounting arrangement.
• Saved result identified: the loaded file belongs to this station and deployment revision.
• Frame meanings preserved: overrides do not substitute names for missing coordinate conversions.
• Direction checked: a worked point confirms the mapping, not just the frame labels.
• Units and rotation format checked: translation scale and quaternion or angle conventions agree.
• Single publisher established: neither static nor dynamic sources compete for the child frame.
• Restart behavior verified: a fresh listener receives the intended calibration after startup.
• Application checks passed: reference-point errors satisfy the documented acceptance limits before motion is enabled.

If hardware is also changing, use the camera finder and camera configuration workflow to review the acquisition requirements separately. For integration help, send the frame tree, selected file conventions, and publisher configuration through applications support. Those details make it possible to distinguish a publication error from a calibration error without guessing.