Two inspection models, one robot, and only one part type ever gets picked. The vision detail view tells another story: both containers are found, one model accepts the instance, the other rejects it, and the robot still goes for the same type every cycle. Run each model on its own and both behave. That pattern points at result arbitration between models that share a scene, not at matching, exposure or calibration. Here you will see why the verdict from the first capture decides the pick, how to confirm it in a few minutes, and how to size each model's search region so its first look is the correct one.
The symptom: each model passes alone, together one type is picked
The set-up is common in mixed picking. Two container types look the same to a geometric matcher, so both inspection models carry the identical geometric model, and the inspection step looks at a small feature - a recess, a label window, a moulded mark - that only one type has. In the per-instance results you see the verdicts: one model up, one down, on the same item. The robot, though, only ever approaches one type. Retraining the models, re-exposing, changing the trigger - nothing moves it. A single model in the cell passes every part you show it, on its own and in mixed trays.
Why the first verdict sticks
Results are arbitrated per instance, not per model. An overlap filter tracks each item found in a capture: the first model that finds and judges it records the verdict, and that status stays with the item for the cycle. If a second model re-detects the same item and scores it acceptable, the earlier rejection still stands. The verdict from the first capture is final for that instance.
That is why both models pass alone. One model has no rival, so nothing overrules it. With two models searching the same space, the outcome is decided by search coverage and evaluation order - not by which type the part really is. If the wrong model reaches the instance first, a good part is dead on arrival, and the accepted verdict your detail view shows belongs to the model whose answer nobody uses.
Rank the causes, then test each
Work down this list; the first two causes cover most cells with this symptom.
| # | Cause | Test that confirms it |
|---|---|---|
| 1 | Both models search the full scene | Open each model's search-region setting. If both cover the whole capture, evaluation order decides every verdict. |
| 2 | The feature sits outside a region, or a region reaches a neighbour | Overlay each region on a capture of a known part at both extremes of placement tolerance. |
| 3 | The inspection does not discriminate | Present one part of each type. If both models accept both parts, the feature was never trained into the models. |
| 4 | Result writes collide downstream | Log every result write with a model ID. Two branches writing one status register is the same failure one layer down. |
| 5 | Two neighbours are grouped as one instance | Place two parts at your minimum pitch. The verdict count must equal the part count. |
A model that accepts the wrong container is the acceptance side of the false positives in a new scene problem, and that checklist doubles as an audit for cause 3.
The fix: one feature and one region per inspection model
Keep the shared geometric model - it is what finds containers at all, whatever the type. Attach each inspection model to the one feature that separates the types, and constrain that model's search with a limit position region anchored to the matched pose. The design rule is one line: the first evaluation of an instance must stand as the final verdict. No rescue by a second model, no re-trigger, no second capture. Where to draw a region, and how the choice differs between sensor types, is the subject of the 2D vs 3D camera ROI guide.
A structured-light 3D camera supplies the poses every region anchors to. The 3D sensors category groups them, and the camera finder filters by type and resolution.
- Type
- Stereo / structured light
When the separating feature is color or print rather than shape, a smart camera mounted over the same scene can run that single inspection while the 3D camera delivers poses; the smart cameras category lists the options. The MV-SC6050C-08M-XBN pairs a 5 MP color sensor and an 8 mm focal length with a multi-color light source, so a feature that differs by color can carry the verdict on its own.
- Interface
- GigE
- Resolution
- 5 MP
- Sensor format
- 1/1.45"
- Shutter
- Global
Both models, the pose matching and the robot handoff live on the controller. The vision controllers category groups the options by LAN-port count and memory. The MV-VC3301H-128G66 runs the stack with 5+ LAN ports and 8 GB of memory, vision software included.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Sizing the inspection region for two look-alike containers
Example inputs for a typical tote-bin cell - substitute your own values where they differ:
- Container footprint 300 x 200 mm, 250 mm high. Feature: a moulded recess 25 mm across, centred 70 mm from the container centre along the long axis.
- Feature placement tolerance in the part frame: plus or minus 4 mm.
- Pose repeatability of the matched container: plus or minus 3 mm.
- Bin layout: 20 mm clearance between containers, so centre pitch is 320 mm in-row and 220 mm across rows.
- Camera: 12 MP over a 1200 x 900 mm scene, 4096 x 3000 px.
The rule, in words: the region width equals the feature diameter plus twice the sum of placement tolerance and pose error, and the region sits centred on the expected feature pose. It must stay inside its own container and clear of the neighbour's feature zone.
Here d is the feature diameter, t_place the feature's placement tolerance in the part frame and t_match the pose repeatability. Adding the errors is a conservative bound; they rarely peak together.
The arithmetic:
- Margin per side: 4 mm + 3 mm = 7 mm.
- Region width: 25 mm + 2 x 7 mm = 39 mm, so fit a 40 x 40 mm region.
- Containment: the feature centre sits 70 mm from the container centre, so the region reaches 70 mm + 20 mm = 90 mm, inside the 150 mm half-length of the 300 mm side.
- Neighbour clearance: features across rows sit 220 mm apart, and two regions span 20 mm + 20 mm = 40 mm of that, leaving 180 mm clear.
- Pixels: 1200 mm / 4096 px = 0.293 mm per pixel, and 25 mm / 0.293 mm = 85 px across the feature. The usual rule of thumb for a stable verdict feature is 10 px or more across, so resolution has wide margin.
Decision: fit a 40 x 40 mm limit position region to each inspection model, centred on the expected feature pose in the part frame. If rejects come back as missed features, widen toward 100 mm - adjacent regions then still leave 220 mm - 100 mm = 120 mm of clearance. Past about 110 mm, half the 220 mm pitch, two regions can touch and share one instance between models, which is the failure you began with. The pitch arithmetic here is the same the 3D palletizing box-sizing guide works through for cartons.
Hand one verdict downstream, once
Constrained regions fix the vision side; the handoff needs the same discipline. One accepted instance must produce one result write, to one address, per cycle. If two model branches set the same robot input or PLC bit, the last write wins on that side, and you get first-result-wins symptoms from a second layer. In ladder logic the trap has a name: same status bit written from two rungs resolves to last-write-wins. Key the pick path on the model that recorded the acceptance, and never re-trigger the scene hoping a rejection flips - the item keeps its status within the cycle.
Arbitration problems rarely stay in one layer; the 3D vision topic page collects the capture-side guides for mixed picking.
When this fix cannot work
Two situations need a different answer. First, a feature the 3D image cannot see: a shallow recess viewed straight down gives almost no depth contrast, and no region size recovers it. Change the viewing angle so the feature casts contrast in the depth data, raise the point-cloud detail - the point-cloud x-y-z resolution guide covers the settings - or add a 2D camera that judges the feature while the 3D camera keeps the poses; capturing 2D and 3D images together from one scene needs one trigger plan for both.
Second, parts with no distinguishing feature at all: then inspection cannot exist, and the fix is upstream. Mark one type, or run the types on separate captures with separate parameters, as set out in the per-part capture parameter switching guide.
Prevention checklist before the next mixed-tray run
- Overlay every limit position region on a live capture of both part types at the extremes of placement tolerance; the feature must stay inside for every pose, or some parts get a wrong first verdict.
- Show one part of each type and read the per-instance log: exactly one acceptance per instance, recorded by the correct model, no verdict changes afterwards.
- Place two parts of the same type at minimum pitch and confirm two items, two verdicts - this catches instance grouping before the robot does.
- Log model ID, instance ID, verdict and timestamp for every result, and review a full mixed tray after every model edit.
- Run the robot in step mode through one pick of each type; one accepted instance must produce one pick call and one result write.
- Retire any capture-again-until-it-passes logic; within a cycle, the first capture's verdict is final by design.
If the region arithmetic above matches your cell, the fix is an afternoon: tighten two regions, run the checklist, release. To match parts to the whole station, the system configurator steps through camera, controller and lighting in order.
Questions
Can I run the two inspection models on separate captures instead?
Yes, and it removes the arbitration problem: each capture evaluates one part type, so no verdict ever competes. The cost is cycle time - two triggered captures and two matching passes per pick cycle instead of one. Keep the shared capture when the cycle budget is tight and the feature is well inside the camera's view; split the captures when the feature is small, offset or easy to miss.
Does the overlap filter merge two different physical parts into one item?
It groups detections that fall within its instance tolerance, so two parts only share a verdict when their matched poses are close enough to count as one detection. At normal bin pitch that does not happen. It becomes possible when a search region is so large that it spans the gap between neighbours, or when part spacing is only a few times the match tolerance - test at your minimum pitch.
What if the distinguishing feature is not visible in the 3D image?
Then no region size can save the inspection. Raise the feature's contrast in the data: change the viewing angle so the recess or step casts depth contrast, or add a 2D camera over the same scene to judge the feature while the 3D camera supplies poses. Very shallow features also need enough point-cloud resolution to register at all.
How do I verify the fix before releasing the robot?
Run vision-only. Present a mixed tray with one part of each type at known positions and confirm exactly one acceptance per instance. Repeat at the extremes of placement tolerance and at minimum bin pitch, then with a full tray. Log model ID, instance ID and verdict for every result; a correct build shows each instance judged once, by the right model, with no verdict changes.
Why did both models pass every test when run one at a time?
A single model has no rival: it searches the scene, finds the instances and records its verdicts, and nothing ever contradicts them. The failure only appears when two models search the same space, because the first model to judge an instance sets its status and the second model's opinion is discarded by the overlap filter. Model-by-model qualification cannot catch it.


