For a manufacturer buying a vision-guided robot, 3D software belongs in the evaluation of the complete operating workflow. A matching algorithm may look impressive while the surrounding tools make commissioning, recovery, or adding a product difficult. Your evaluation should follow a recorded scene all the way from capture to a verified robot action.
Map the software boundary
Ask the supplier to draw what its product does and what another component must do. Does it acquire images, build a point cloud, identify objects, calculate grasp candidates, check access, or command the robot? A license for one of those functions should not be mistaken for a complete application.
MVTec 3D matching documents shape-based and surface-based localization methods. Use your parts to compare proposed approaches rather than choosing by algorithm name. A known CAD model, flexible package, and irregular casting can require different evaluation scenes and different definitions of a usable result.
Record the data formats at each boundary. Include coordinate conventions, length units, timestamps, and how invalid data is represented. Ask the vendor to demonstrate a deliberately incorrect or missing input and show the resulting diagnostic. Silent conversion errors are much harder to discover after the robot has been integrated.
Build a replay library
Save representative raw captures and label the required result for each. Include empty scenes, overlapping targets, difficult surfaces, and plausible wrong products. Keep a separate acceptance set. The replay library lets you compare settings and upgrades without rearranging a physical scene every time.
Measure success by the downstream decision. A high model score is not the objective if it selects an inaccessible face or confuses an orientation. Include scenes in which the correct answer is to decline a pick. The evaluation should reward a dependable operating boundary rather than confidence at any cost.
Zivid bin-picking and machine-tending tutorial notes that computer specifications affect transfer and processing. Benchmark on the proposed production hardware with logging enabled. Ask whether published timing includes acquisition, preprocessing, localization, and the robot interface, or only one algorithm stage.
Evaluate calibration and transforms
OpenCV camera calibration tutorial documents camera parameters and reprojection-error calculation. Ask how the proposed software stores calibration, verifies that the correct file is loaded, and prevents accidental unit or frame mismatches. A low calibration residual should be followed by independent physical validation.
Use the calibration-board checklist to specify the reference and records. The software should expose enough information to diagnose a camera that sees the part correctly while the robot approaches the wrong location. Clarify whether your team can inspect and export transformations without contacting the original developer.
Compare operating cost and access
| Commercial item | Question to answer before purchase |
|---|---|
| Runtime | How many machines, cameras, or instances does the license cover? |
| Development | What is required to edit recipes and add a product? |
| Deployment | Can an approved configuration run without an internet connection? |
| Replacement | What happens when the production computer fails? |
| Updates | Who pays for support, upgrades, validation, and rollback? |
Request actual license terms rather than interpreting a marketing phrase such as perpetual or unlimited. Keep optional modules, required hardware, and recurring services visible in the quote. Decide who owns custom application code and whether another integrator can maintain it.
Test maintainability before approval
Hypothetical evaluation: two packages localize the same part equally well. In one, a trained technician can diagnose a bad capture and restore a saved recipe. In the other, each change requires external development. If your factory changes products frequently, that difference can dominate the purchase decision even without a faster algorithm.
Have the intended user add a bounded product variant, adjust an approved parameter, and restore a previous version under supervision. Record the training and permissions required. Test disk-full behavior, lost camera connection, and a restart with an incomplete job through a controlled acceptance procedure.
For loose components, use the bin-picking acceptance guide to define realistic results. Then attach the software deliverables to the integration plan so performance and long-term ownership remain part of the same purchase.
When selecting software for a FAIRINO-based cell, make the proposed robot handoff part of the evaluation. Use the FAIRINO selection guide to define the task, then ask the software supplier to demonstrate coordinate conventions, no-result behavior, and recovery with the intended controller arrangement. Include licenses and engineering work separately in the project scope.
Request a FAIRINO robot quote with your software shortlist and required outputs. State which interface tests are complete and which remain acceptance conditions; do not treat an SDK listing as a finished integration.
Sources and further reading
Find the FAIRINO robot for your application
Share your part weight, working area, and production target. Request a FAIRINO model recommendation and discuss a quote for your project.
Request a FAIRINO quote