3D fine matching input mismatch: check clouds and poses

A fine-registration error can look like a geometry problem when the actual fault is an incorrectly connected data structure. This troubleshooting procedure is for engineers passing scene point clouds and coarse-match pose candidates into a refinement step. You will separate valid multiple-hypothesis output from an input mismatch, trace each pose to its intended cloud, and verify transforms before adjusting registration settings. A different number of clouds and total poses is not enough, by itself, to identify the fault.

1. Separate an input error from a registration failure

Fine matching generally refines an approximate alignment between model geometry and scene geometry. However, the accepted input structure depends on the software and operation. Some interfaces accept one cloud and several candidate poses. Others require grouped lists, individual cloud-pose pairs, or additional model identifiers.

Start with the exact error message and the documented input contract for your installed software version. Obtain documentation and software packages from the manufacturer or its authorized distributors.

Use the point at which processing stops to guide your first test:

These are diagnostic priorities, not guarantees about a particular implementation. A unit error can also cause a documented range check to reject an input immediately.

Save the failing inputs before changing settings. Otherwise, changing data and parameters together makes the cause difficult to isolate.

2. Check nesting before counting individual poses

Distinguish the number of outer groups from the number of poses inside those groups. A scene cloud can produce several coarse-match hypotheses because of symmetry, repeated features, or ambiguous geometry.

For example, consider three scene clouds with candidate counts of one, two and one:

scene_clouds = [cloud_A, cloud_B, cloud_C]

pose_groups = [
    [pose_A1],
    [pose_B1, pose_B2],
    [pose_C1]
]

There are three cloud entries, three pose groups and four candidate poses. That structure can be valid when the interface defines each outer pose group as belonging to the corresponding cloud. It is not evidence that one cloud is missing.

The relevant counts are:

A grouped interface might require the outer pose-group count to equal G while allowing H to differ. A pair-based interface might instead require four explicit cloud-pose records, with the same cloud referenced by multiple records.

Do not flatten nested pose groups merely to make the display look simpler. Flattening removes grouping information unless you preserve an explicit association for every candidate.

3. Trace cloud-to-pose correspondence through every operation

The next likely problem is association loss. Filtering, sorting, merging and asynchronous processing can change list order without producing an obvious type error.

Record a small manifest at the boundary between coarse and fine matching. Keep application identifiers separate from the actual arrays passed into the documented interface.

Check each processing operation explicitly:

1. When removing a cloud, remove or reroute its associated candidate group according to the documented contract.
2. When sorting clouds, apply the same permutation to positional pose groups.
3. When rejecting an individual candidate, preserve the association of every remaining candidate.
4. When processing asynchronously, join by capture and cloud identifiers rather than arrival order.
5. When combining clouds, transform the associated poses into the combined cloud frame before refinement, if that is the frame the operation requires.

For example, sorting clouds from [A, B, C] to [C, A, B] while retaining pose groups in their original order creates a mismatch despite unchanged counts.

An empty candidate group also needs deliberate handling. Depending on the interface, it may be valid, require skipping that cloud, or be rejected. Never replace a missing hypothesis with an identity transform simply to fill an entry.

4. Verify pose direction, representation and reference frames

A pose is not meaningful without its source and destination frames. Establish whether each candidate maps model coordinates into scene coordinates, or scene coordinates into model coordinates.

For a model-to-scene transform, use the convention:

Here, R is a proper rotation matrix and t is a translation expressed in the scene frame. The inverse equation assumes a rigid transform without scale or reflection.

Choose a known model reference point and calculate where the candidate places it. For the model origin, the transformed point is simply the translation vector. Display that position with the scene cloud before running refinement.

The camera pose initial-guess frame explanation helps distinguish a camera pose from an object pose. If the display appears mirrored or inverted, also check the 3D ROI coordinate-frame diagnostic.

Do not identify pose conventions from tuple length alone. A seven-element record might contain translation and a quaternion, but component order remains interface-specific. Verify:

• Translation field order and coordinate unit.
• Quaternion component order, when used.
• Quaternion normalization requirements.
• Angle units and rotation sequence for Euler-angle inputs.
• Matrix row or column layout and vector multiplication convention.
• Whether the pose refers to the camera, model, world frame, or a cropped cloud frame.

Cropping a point cloud does not necessarily change its coordinate frame. A separate recentering operation does. If the pipeline changes optical-frame conventions, follow the optical-to-camera point-cloud transform explanation before composing transforms.

5. Check scale with a numerical example

A plausible-looking pose can still be unusable if the model, scene and translation use different units. Check all three independently.

Suppose a model reference point, after rotation, is at (20, 0, 0) millimeters. Its candidate translation is (400, 100, 800) millimeters. The expected scene position is:

If the scene is stored in meters but the translation is passed unchanged as (400, 100, 800), the translation is numerically 1,000 times too large. Refinement settings cannot repair that interpretation error.

Compare a known physical dimension against both the model and scene bounding boxes. A part approximately 80 mm wide should span approximately 0.080 m when represented in meters. Perspective and partial visibility affect observed coverage, so use a visible reference dimension rather than assuming the entire part is present.

The depth-scale mismatch diagnostic covers related depth interpretation checks. Here, the additional requirement is that pose translations and reference geometry use the same scale as the scene.

6. Reduce the case to one known cloud and one candidate

Build a minimal offline reproduction using saved data. Do not connect this diagnostic test to motion commands.

1. Freeze one acquisition. Save the exact scene geometry, model geometry, candidate pose and preprocessing settings.
2. Select one association. Choose a candidate whose transformed model visibly overlaps its assigned cloud.
3. Construct the documented input. Preserve required nesting even when there is only one candidate.
4. Check numeric validity. Confirm that the pose is finite and that invalid cloud points are handled as the interface specifies.
5. Run refinement without additional filtering changes. Record the error or convergence status.
6. Add another candidate for the same cloud. This tests multiple-hypothesis handling without changing cloud association.
7. Add another cloud group. This tests outer grouping and indexing independently.
8. Restore upstream operations individually. Reintroduce filtering, sorting and asynchronous processing until the failure returns.

If one candidate works but adding another candidate for the same cloud fails, investigate the supported cardinality and nesting first. That observation does not prove that multiple candidates are prohibited.

If each cloud works independently but the combined input fails, inspect group association, empty groups and capture identity. If even the single-pair case fails, return to the required types, frames, scale and geometry.

For native or device-backed arrays, buffer shape and ownership may also matter. Check the point-cloud memory-layout guide when the failing boundary involves strides, alignment or packed point records.

7. Tune registration only after the inputs pass

Once the data contract is correct, evaluate whether the initial alignment lies within the algorithm's useful convergence region. Fine registration is not generally a substitute for a missing or unrelated coarse alignment.

Inspect the transformed model against the intended scene cloud. Look for actual shared surfaces, not just nearby bounding boxes. Sparse edges, repetitive geometry, partial views and inconsistent surface normals can make the solution ambiguous.

Change one setting at a time and keep the saved input fixed. Candidate settings may include correspondence distance, sampling density, normal estimation and iteration limits, depending on the documented algorithm.

For illustration, a correspondence gate of 5 mm would reject a nearest-neighbor separation of 12 mm. Increasing the iteration count does not change that gate. Widening the gate might admit those points, but can also admit neighboring objects and produce an incorrect alignment.

Likewise, a low residual does not establish correct object identity. A symmetric part may support several similar alignments. Check convergence status, accepted correspondence count, spatial coverage and the final overlay together.

Before comparing overlap or fitness values, establish their definitions. One implementation may divide accepted correspondences by model points; another may use scene points or sampled points. Those values are not directly interchangeable.

8. Separate hardware selection from the software fault

Replacing a sensor will not correct lost pose grouping. Consider acquisition changes only when the saved cloud lacks the geometry needed for a stable match.

When reviewing 3D sensors, use the camera finder to explore acquisition options. Confirm the required geometry output, coordinate conventions and software interface before choosing a part.

The MV-DLS300P-04 is listed as a laser galvanometer stereo camera. Its catalog classification does not establish compatibility with a particular fine-matching operation.

The MV-DPS200P-02 is listed as a projected structured-light 3D camera. Confirm the required acquisition and integration details for your application before selection.

If processing will run on vision controllers, validate the software runtime, required interfaces, buffer ownership and processing load separately. Camera connectivity alone does not establish support for the required registration software.

For an existing installation, make the minimal saved-data example pass on the current processing platform before changing hardware. This preserves a useful baseline for later integration testing.

9. Verify the correction before restoring production use

Repeat the original failing capture after correcting the suspected mismatch. Then test additional saved captures without changing the validated input structure.

Use this release checklist:

• Input contract: Types, nesting and required fields match the installed operation's documentation.
• Candidate grouping: Each pose remains associated with its intended cloud and reference model.
• Capture consistency: No pose is paired with geometry from another acquisition.
• Empty-case behavior: Missing clouds and zero-candidate groups follow a documented path.
• Frames and units: Cloud coordinates, model geometry and translation values agree.
• Transform direction: A known reference point lands where the overlay predicts.
• Geometric acceptance: Alignment is checked against application tolerances, not only a success flag.
• Repeatability: Filtering, sorting and restart sequences do not change association unexpectedly.

Include at least one valid multi-candidate case and one deliberate no-match case. A correction that works only when every cloud produces exactly one pose has not exercised the original ambiguity.

If the documented structure still fails, prepare the error text, software version, input manifest and smallest reproducible saved dataset for support. Remove confidential geometry where possible without changing the failure.

For help selecting acquisition hardware or reviewing integration requirements, contact the applications team with that evidence. Resolve the cloud-pose contract first; then use registration tuning to improve an already valid alignment.