A SCARA vision sorting cell is credible when it can explain which image produced a target, which coordinate transform was used, why the pick point was valid, whether the gripper obtained custody, and where the part was placed. Robot motion alone cannot prove that the perception-to-action chain is correct.
Key takeaways
- Define image validity before accepting a detection or pose estimate.
- Keep camera, work-surface, robot-base, tool, and pick-point frames explicit and versioned.
- Screen reachability, neighbor clearance, tool approach, and gripper compatibility before issuing motion.
- Separate detection confidence, pick permission, grasp confirmation, placement confirmation, and final disposition.
- Revalidate after any change that can move the image, coordinate chain, target definition, tool, or work surface.
What the selected footage supports—and what it cannot prove
The reviewed material shows a SCARA-style robot repeatedly approaching multiple flat parts on an illuminated work area and moving between the field and a nearby container or destination. The parts appear at different positions within the visible field, and the robot performs repeated pick-or-place motions. Those observations support a bounded discussion of variable presentation, target selection, planar coordinate mapping, grasp planning, destination control, and exception handling.
The footage does not identify the camera, lens, lighting specification, exposure, calibration method, image-processing algorithm, training data, confidence threshold, part dimensions, surface properties, coordinate error, robot accuracy, gripper sensing, pick success, sort correctness, cycle time, reject logic, traceability, quality result, safety architecture, or deployed production performance. EVST therefore uses it as bounded sequence evidence, not as proof of vision accuracy, algorithm capability, throughput, quality, compliance, or site acceptance.
The bright field and repeated motion do not establish that every pick was vision-guided. The article treats vision guidance as the approved topic and uses the footage only for observable interaction, while the technical sections state what a project would need to verify.
How to plan SCARA vision sorting
Begin with the target definition. List each accepted part type, orientation range, visible features, permitted overlap, expected background, surface condition, allowable occlusion, and destination. Define what must happen when the system cannot distinguish two parts or cannot produce a usable pick point. An unknown target should remain unknown rather than being forced into the closest known class.
Next, define the acquisition state. Record the camera and lens configuration, mounting method, illumination, working distance, field of view, focus, exposure behavior, trigger, image identifier, timestamp, and any requirement for the work area to be stationary. The system should know whether an image is valid for the current physical scene before it uses the result for motion.
Then define the action state. A detected location becomes a robot target only after coordinate transformation, reachability, tool orientation, collision or neighbor-clearance screening, destination availability, and gripper rules are satisfied. The final state is not “robot moved”; it is confirmed part custody followed by confirmed placement or a controlled exception.
Control the image before trusting the coordinate
Lighting, background, reflections, shadows, focus, motion, and part presentation influence what appears in an image. A vision recipe should therefore include an image-validity check rather than assuming any triggered frame is usable. The validity rule may consider field coverage, exposure range, focus evidence, expected reference features, scene motion, or another project-specific signal.
The A3/RIA machine-vision guidance discusses camera-to-robot calibration, stable lighting, and feedback as system-level concerns for robot guidance. The page supports the need to integrate image and robot calculations; it does not provide a performance result for this cell.
Where parts move on a conveyor or another dynamic feed, timestamps and motion compensation become part of the state contract. A target calculated from an old frame can be geometrically correct for a location the part no longer occupies. The selected footage does not establish a moving-feed architecture, so this remains a project decision.
Close the camera-to-robot reference chain
Write the reference chain from image measurement to commanded pick. Depending on architecture, it can include image coordinates, camera coordinates, a work-surface or conveyor frame, robot-base coordinates, tool-center-point coordinates, and a part-specific grasp frame. Each transform needs an owner, method, stored version, validity condition, and change trigger.
The official OpenCV camera-calibration and 3D-reconstruction documentation describes camera models, distortion, calibration, pose, and coordinate transformations. It supports the principle that image measurements must be interpreted through a calibrated model; it does not validate the hardware, setup, or result of a particular industrial cell.
Robot repeatability is only one contributor to the final pick. Camera mounting, lens behavior, work-surface flatness, calibration target, tool-center-point setup, gripper compliance, part height, and thermal or mechanical change can shift the relationship. The project should verify the complete chain with representative targets across the required field, not substitute a robot datasheet value for system accuracy.
Detection-to-placement handshake table
| State | Evidence to define | Permitted action | If evidence is missing or contradictory |
|---|---|---|---|
| Scene ready | Presentation state, field clear condition, lighting state, trigger permission, and required motion status | Acquire an image with identifier and timestamp | Do not use an uncertain scene; wait, re-present, or route to exception handling |
| Image valid | Expected field, exposure, focus, reference features, and recipe identity | Run the approved detection or pose method | Reject the frame and preserve the reason without generating a robot target |
| Target classified | Part class, orientation, visible feature set, overlap or occlusion rule, and uncertainty state | Create a candidate pick point and destination | Send the part to unknown, recheck, or controlled manual disposition |
| Coordinate mapped | Calibration version, camera or surface frame, robot frame, tool frame, target height, and pick offset | Screen the candidate in robot coordinates | Block motion and diagnose the invalid or out-of-range mapping |
| Pick permitted | Reachability, approach, tool orientation, edge and neighbor clearance, destination capacity, and zone permission | Execute the approved approach and pickup sequence | Select another valid target or enter exception handling |
| Custody confirmed | Project-specific gripper or part evidence tied to the selected target | Remove the target from the available queue and transport it | Keep target status disputed; re-image or recover without assuming success |
| Placement confirmed | Correct destination, capacity, release command, release evidence, and optional destination check | Record disposition and permit the next target | Preserve part identity and use the defined recheck or recovery route |
Choose the simplest presentation strategy that controls uncertainty
A fixed mechanical presentation can remove most position uncertainty and may need only presence or orientation verification. A fixed camera over a controlled field can support variable planar positions when lighting, part separation, calibration, and pick rules are stable. More random, overlapping, reflective, deformable, or height-varying parts may require additional sensing, presentation control, or a different robot and gripper concept.
Vision should reduce defined uncertainty, not excuse uncontrolled feeding. Adding a camera can also add trigger, lighting, calibration, image-validity, compute-time, target-selection, and exception states. Compare concepts by the same accepted-part definition, incoming range, presentation burden, required orientations, destination rules, changeover, recovery, and validation effort.
A SCARA candidate is strongest where the task remains largely planar and the approach and tool orientation fit the available axes. If a part requires complex reorientation, access around obstacles, or large height variation, the process may need a different motion architecture. This is an application-screening boundary rather than a performance claim.
Define a pick point the gripper can actually use
A detected object can have several geometrically possible points but only a subset may be valid for the tool. Define allowed contact surfaces, edge distance, neighbor clearance, vacuum or finger footprint, part stiffness, surface sensitivity, required orientation, and tool approach. If the target is too close to another part or the field boundary, the correct action may be to wait, re-present, choose another target, or route it as an exception.
The pick-point rule should consider part height and the relationship between the observed plane and the real contact plane. A planar image coordinate without the required height or depth assumption can map to an incorrect robot target. The project must state when a fixed-height assumption is valid and how variation is detected or contained.
After the command, custody still needs evidence. Vacuum state, finger position, part-present sensing, weight, image recheck, destination confirmation, or another method may contribute. None should be assumed from the footage, and no one signal is universally sufficient.
Keep unknown, reject, and recheck states separate
A sorter needs more than accepted destinations. Define unknown class, no detection, multiple or overlapping target, invalid image, unreachable pick, failed grasp, disputed custody, wrong destination, and full reject container. Each state needs a permitted response, diagnostic record, part owner, and route back to production or final disposition.
Do not turn low-confidence or contradictory results into an automatic best guess merely to avoid stopping. A recheck can use a new image, changed presentation, a secondary view, or controlled human review, but the article does not prescribe a universal confidence threshold or recheck count. Those values require representative validation and the project’s quality rules.
Traceability should connect image identifier, recipe, calibration version, detected target, chosen pick point, robot result, destination, exception, and operator intervention when applicable. The required data retention and quality record depend on the product and management system.
Separate production logic from safety-related functions
Vision classification and pick permission belong to production logic unless a separately specified and validated safety architecture assigns them another role. A camera result used for sorting should not be presented as a safety function merely because it can see the work area.
The official ISO 10218-2:2025 source page describes requirements for industrial robot application and cell integration through design, integration, commissioning, operation, maintenance, and decommissioning. The official ISO 12100:2010 source page describes machinery risk-assessment and risk-reduction principles across relevant lifecycle phases. Applicable editions, regulations, required performance, and validation remain installation-specific.
The OSHA Robotics Overview identifies programming, maintenance, testing, setup, and adjustment as important non-routine robot hazard contexts. Vision-sorting planning should include camera and lighting setup, calibration, teaching, clearing a disputed part, gripper maintenance, container change, recovery, and restart—not only normal automatic picks. OSHA material is United States context rather than a universal legal conclusion.
Validate the complete perception-to-action chain
Build a representative condition matrix before declaring the cell ready. Include normal parts across the allowed field, edge positions, orientation range, expected surface variation, lighting variation within the controlled envelope, permitted occlusion, close neighbors, empty scenes, unknown parts, damaged parts, full destinations, failed pickup, dropped part, stale image, calibration check failure, controlled stop, and restart.
Record the source scene, image identifier, recipe, calibration and tool versions, detected class, pose or pick point, validity result, robot target, grasp evidence, destination, disposition, and observed exception. Keep image evaluation, robot motion, grasp custody, and final sorting correctness as separate outcomes so one successful step cannot conceal another failure.
Repeat defined checks after camera, lens, illumination, exposure, mount, work surface, calibration target, gripper, tool-center point, robot, controller, network, algorithm, software, or part recipe changes that can affect the chain. Numerical accuracy, detection performance, cycle, and acceptance limits must come from the actual project.
Four bounded citable statements
Statement 1: A vision-guided sort is easier to diagnose when image validity, target identity, coordinate mapping, pick permission, grasp custody, and placement confirmation are stored as separate states. This is an EVST engineering method, not a universal compliance rule.
Statement 2: A detected image location becomes a robot target only after the applicable coordinate chain, tool offset, target height, reachability, and clearance rules have been applied.
Statement 3: A successful robot move does not by itself prove correct detection, correct coordinate mapping, successful grasp, or correct sorting disposition.
Statement 4: The selected footage supports observation of repeated SCARA pick-or-place motion across variable planar part positions, but it does not establish vision accuracy, pick success, sorting correctness, cycle time, quality, safeguarding performance, or deployment.
The TRACE review model
EVST uses TRACE as a planning aid for early vision-sorting reviews. It organizes project questions and does not replace representative trials, calibration verification, machinery risk assessment, safety validation, or an acceptance specification.
- T — Target definition: part classes, orientations, visible features, allowed overlap, pick surfaces, and destinations.
- R — Reference chain: image, camera, work surface, robot base, tool, part, and destination frames.
- A — Acquisition validity: lighting, focus, field, trigger, timestamp, scene state, and recipe.
- C — Custody: pick permission, gripper evidence, target queue, release, and placement confirmation.
- E — Exceptions and evolution: unknown, recheck, reject, recovery, change triggers, and revalidation.
Project inputs for a SCARA vision-sorting concept
Prepare representative part samples, class list, drawings and mass, surface and color variation, incoming position and orientation range, overlap and occlusion rules, background and presentation method, target destinations, accepted sorting rule, unknown and reject route, required traceability, lighting constraints, available field, working distance, camera mounting options, gripper contact limits, part height range, SCARA work envelope, upstream and downstream signals, target accepted output, changeover needs, available footprint, maintenance tasks, and installation country.
For adjacent context, see the EVST SCARA application guide, the robot material-handling overview, and the industrial automation line integration overview. Those pages cover broad robot and handling selection; this guide is limited to the image-to-coordinate-to-pick-to-disposition evidence chain.
References
- Association for Advancing Automation — SCARA applications overview
- A3/RIA — Machine Vision for Robot Guidance
- OpenCV — Camera Calibration and 3D Reconstruction
- ISO 10218-2:2025 — Robotics safety requirements for industrial robot applications and robot cells
- ISO 12100:2010 — Safety of machinery, risk assessment and risk reduction
- OSHA Robotics Overview
Frequently asked questions
Does a vision detection coordinate go directly to the SCARA?
It should pass through the defined camera, work-surface, robot-base, tool, and part reference chain, then through target-height, reachability, approach, edge, neighbor, and destination checks. The exact chain depends on camera placement and cell architecture.
How should the cell handle an uncertain or overlapping part?
Keep it out of the accepted automatic path. The project can use re-presentation, a new image, a secondary view, another target, reject routing, or controlled human review, but the state and final disposition should remain traceable.
How is a successful pick confirmed?
Use project-specific custody evidence such as vacuum state, gripper position, part-present sensing, image recheck, destination confirmation, or a justified combination. A motion command or expected timing alone does not prove that the intended part was acquired.
What changes should trigger revalidation?
Changes to the camera, lens, lighting, exposure, mount, work surface, calibration target, gripper, tool-center point, robot, controller, network, algorithm, software, part, recipe, presentation, or destination can affect the chain and should be assessed under change control.