Software & integration

Part positioning: acceptance and motion handoff

Validate original-pixel localization separately from approved motion mapping; test ambiguous targets, stale results and physical pickup response.

Send samples for engineering review
Part positioning: acceptance and motion handoff
Engineering illustration, not a photograph or measured result.

Inspection task

Seal independently annotated pixel centers and declare the allowed error before testing. If the project includes robot movement, create a separate physical acceptance plan with verified transform and tool references. A horizontal center check does not authorize a pick. Include no target, multiple targets and height changes that violate the plane assumption.

Prerequisites and sample controls

Declare whether the task is a pixel-position check or a calibrated motion command. The simple fixed-station baseline checks the horizontal center of one separated dark target. It does not certify vertical position, rotation, height or a robot pick. Prepare one visible target, no target and multiple targets; preserve the original coordinate origin and independently annotated centers.

Choose the camera route

Use a fixed area-scan camera for a stable plane and observable feature. A global-shutter route helps when the part still moves during capture. If height or overlap affects the pickup point, evaluate a verified depth route instead of treating a 2D center as a 3D pose. Camera-to-robot transformation and tool calibration are separate from image localization.

Run the controlled procedure

Agree the decision rules, permitted variation and required line response before starting acceptance. Freeze the workflow, dataset, runtime, materials and thresholds together. Keep the acceptance answer set independent of tuning; if its answers have already influenced changes, disclose that reuse and obtain a new independent set. Human review must remain separate from model predictions and automatic workflow editing.

  1. Freeze original-image coordinate semantics and pixel answers.
  2. Measure localization error across the allowed view.
  3. Test stale, duplicate and ambiguous result handling.
  4. Verify approved physical points under a safe, separately controlled motion test.

Process map

Independent image answers validate localization; separately verified mapping and physical motion complete a robot handoff.

  1. Frozen candidate
  2. Independent test
  3. Line response
  4. Local approval
Engineering illustration, not a photograph or measured result.
View full-size diagram

Record the evidence

Report pixel error independently from physical placement error and review frequency. Record runtime, calibration/map identity and actual target condition. Do not combine successful display overlays with successful physical picks into one unexplained score.

Split the acceptance evidence into localization, transformation and physical action records. The localization record contains the original image, independently marked target, reported pixel center, uniqueness and any unobserved pose fields. The transformation record identifies the approved coordinate map and the physical geometry it permits. The action record states the actual target used, tool reference, observed motion and independent physical outcome. Link these records by the same current event identity while keeping their errors in the appropriate units. A good localization record does not make an invalid plane acceptable, and a successful physical pick cannot excuse wrong image identity. Declare which record establishes each project criterion so the final report can be reviewed without interpreting a mixed success percentage.

Illustrative recording sheet; enter your own results
ControlRequired observationDecision boundary
X32: one visible targetIllustrative original-image center x = 32 pxExample window: 28–35 px; not a robot tolerance
X26: one visible targetIllustrative original-image center x = 26 pxOutside the example horizontal window
M: multiple or hidden targetsNo unique observable target centerReview; no motion command inferred

Diagnose failed cases

A late but correct center can move the robot toward a previous part. A unique center with missing height can also be physically unusable. Reject results outside the current request or declared geometry, and never invent missing pose components.

Failure isolation

Compare valid current localization, stale coordinates and an invalid plane. A usable motion result requires every declared boundary to hold.

  1. Current center
  2. Stale center
  3. Invalid plane
  4. Approved motion
Engineering illustration, not a photograph or measured result.
View full-size diagram

Validate independently

Test complete events, including capture failure, ambiguous evidence, timeout and duplicate delivery. Tie every output to the current part and request identity. The integration must handle pass, fail and review/no-result explicitly rather than converting missing evidence to pass. Record observed latency and the final actuator response; a software result alone does not prove that the physical part was correctly handled.

Accept the pixel stage only against independent annotations; accept motion only against the separately agreed physical criteria. Review the mapping after camera, fixture or tool changes.

Test invalid and stale events through the entire proposed handoff before operational movement. Use the locally approved safe commissioning method to introduce no target, multiple targets, a delayed center and a result from another request. Confirm that none is converted into a normal pickup command by default values or reuse of the previous pose. Check that the receiving interface can preserve unknown angle and height rather than replacing them with ordinary zeros. If the project needs those fields, a separately verified route must provide them with their own validity evidence. Then test the permitted physical conditions independently, including field locations and presentation variation that affect the transform. Keep the approved mapping bound to its camera, fixture and tool configuration. A later configuration change requires a new applicability review; saving an updated workflow is not enough to preserve the earlier physical approval.

Continue the engineering handoff

A candidate identity and a review archive do not constitute an approved executable release. Confirm the installed package, dependencies and active configuration locally. Any activation or rollback procedure must be verified on the actual runtime and kept outside an active job. Do not promise completed package activation or production acceptance from development comparison results.

Save the original image and the resulting record together.

Sources and technical references

These references explain the methods and limits used in this tutorial. Example checks are guidance; production acceptance requires evidence from your own samples.

  1. Visual inspection system design checklistDeyi Vision

    Define sample decisions, station constraints and measurable acceptance before hardware selection.

    Checked
  2. Structural analysis and shape descriptorsOpenCV

    Connected component areas and centroids describe image regions, not hidden physical part counts.

    Checked
  3. 2D and 3D machine vision selectionDeyi Vision

    Image contrast and calibrated depth answer different inspection questions.

    Checked

Engineering review

Bring the inspection problem and the evidence.

Send sample images, your current setup and the check that failed. Include field of view, working distance, line speed and acceptance criteria for a practical review.

Send samples for engineering review
Contact

Direct RFQ contact

Talk to engineering about the inspection problem.

Send sample images, competitor model, FOV, working distance and line speed before model selection.

Target: selection brief within 24h
Send sample images