Why Does ABB CRobT Mismatch with Robot-Held Frames?

A repeatable TCP translation mismatch of about 1.322 mm appears after inverting the robot-held work-object result, even though the orientation matches. That error is slightly larger than the 1.3 mm object spacing, so the transformed target cannot be used for placement until the coordinate chains agree.

Wrong fixes and why they fail

Changing numeric storage, adjusting load data, or repeatedly sampling the same position does not repair a frame-definition mismatch.

Coordinate-chain cause

The number that matters is the relative translation after both results are expressed in reciprocal frames. For the captured values, pose1 is approximately [0.000420381,-0.000173362,-0.00047082] mm and pose3 is [0.0335206,0.362376,1.27074] mm. Their component error is therefore approximately [0.0331002,0.3625494,1.27121082] mm.

The resulting magnitude is:

error = sqrt(dx^2 + dy^2 + dz^2)
      = sqrt(0.0331002^2 + 0.3625494^2 + 1.27121082^2)
      ≈ 1.322 mm

This is geometry, not motion timing. The matching quaternion values show that the reported discrepancy is translational.

The two calls use different semantic chains. The first reads tool0 against wobj0. The second reads tool0_not_held against wobj0_held, then inverts that result. Those outputs become reciprocals only when the stationary tool and robot-held work object describe the same physical interface, use compatible parent frames, and attach the moving frame to the correct mechanical unit.

The declared work object is [TRUE,TRUE,"",...]: it is marked robot-held, but its user frame is also marked fixed/programmed and its mechanical-unit string is empty. That combination does not define the moving attachment chain required for a robot-held frame. Inverting its calculated pose therefore does not reproduce the standard tool/work-object result.

Quantity and frame audit

Also audit every identity pose in the declarations. An identity value means zero displacement from its declared parent; it does not mean “the same frame” when two objects have different parents. The nonzero robot base frame makes that distinction visible.

Correction procedure

1. Capture two identical CRobT calls back-to-back into separate persistent robtarget variables. Compare the complete results to exclude motion or asynchronous task updates.
2. Record the first chain using tool0 and wobj0. Keep the unmodified robtarget so translation, rotation, configuration, and external-axis fields remain available for diagnosis.
3. Record the stationary-tool/held-work-object chain into another robtarget. Convert only after the raw target has been saved.
4. Correct the held work-object definition so its user frame is movable and associated with the robot mechanical unit that physically carries it. Read the exact mechanical-unit name from the controller configuration; an empty string cannot identify that attachment.
5. Define the stationary tool from its actual fixed reference. Its frame must represent the same physical interface used as the reciprocal endpoint of the held work object.
6. Run poseinv on the corrected second pose and calculate the relative translation and rotation against the first pose.
7. Repeat the capture at several robot configurations. A correct coordinate relationship remains consistent as the axes change; a coincidental match at one pose does not validate the chain.

A useful sampling pattern is:

p_CRobT1 := CRobT(\Tool:=tool0, \WObj:=wobj0);
p_CRobT2 := CRobT(\Tool:=tool0, \WObj:=wobj0);
p_CRobT3 := CRobT(\Tool:=tool0_not_held, \WObj:=wobj0_held);
pose1 := target_TO_POSE(p_CRobT1);
pose2 := target_TO_POSE(p_CRobT3);
pose3 := poseinv(pose2);

If p_CRobT1 and p_CRobT2 differ, investigate task execution and sampling before analyzing frame inversion. If they match while pose1 and pose3 do not, continue with the attachment audit.

Verification criteria

Verify the correction numerically before executing close-pitch motion. Calculate a relative transform; avoid comparing only formatted screen values. The translation residual must fit the process tolerance with margin below the 1.3 mm pitch.

Compare rotations as orientations rather than raw quaternion signs because a quaternion and its negation represent the same orientation. In this capture, the stored quaternion components already match, so translation remains the deciding quantity.

Use CJointT, CalcJointT, and CalcRobT only as secondary checks. Inverse kinematics also depends on robot configuration and solution selection, so differing joint values do not by themselves prove that CRobT or poseinv lost precision. Preserve the configuration fields when comparing calculated robtarget values.

Recurring diagnostic pitfalls

• Treating an identity pose as globally identical while its parent coordinate system changes.
• Setting the robot-held flag without defining how the movable user frame attaches to a mechanical unit.
• Discarding the configuration and external-axis fields before the raw robtarget has been inspected.
• Converting the final value to dnum and expecting earlier transform calculations to change.
• Comparing quaternion components without accounting for equivalent sign representations.
• Testing only one robot configuration, where separate frame errors may partially cancel.
• Escalating a possible controller defect without recording the RobotWare version, robot type, declarations, raw targets, and repeatable test sequence.

FAQ