Detect multiple part types in one image instead of per-type locates

A wrist camera that sorts mixed parts usually ends up with one camera locate node per part type, and the cycle time becomes the sum of its misses: search for a square, miss, search for a triangle, miss, search for a star, hit. Each attempt buys a fresh picture plus a full search, so a three-type program can spend 6-9 s photographing the same part before the robot moves. The fix is structural, not a faster processor: take one picture, run one locate step that matches every taught shape at once, and branch the sort on the class it returns. This guide walks the conversion step by step, with the cycle-time arithmetic, a worked example for three shape classes fed in random order, camera choices for the single-image route, and the cases where per-type locates stay right. If you are still at the feasibility stage, start with the vision locate feasibility checklist.

Why one locate node per part type is slow

Each camera locate node owns its own acquisition, its own taught model and its own search, and the nodes run in sequence. A miss still costs the whole picture-plus-search; on a wrist-camera locate node that scope lands at 2-3 s. Nothing moves between those pictures, so every re-acquire before the hit adds time and adds no information.

The cost is wider than the worst case. With N part types arriving in random order and a fixed search order, the hit lands on attempt N at worst and after (N + 1) / 2 attempts on average — two draws out of three for N = 3.

If your program already chains several locate nodes, the two-locate-node waypoint rename pattern shows how their outputs interact, and why the chain grows awkward as nodes multiply.

One picture, one multi-class locate, one branch

The replacement is a single multi-class locate step. You teach every shape as a model inside one node; it searches the same picture for all of them and returns the winning class plus pose. The robot reads the class and jumps to that shape's sort branch, so whatever arrives on the belt, the vision step costs one acquisition and one search pass.

The savings compound: one exposure to tune instead of one per node, one timing number to hold, and no pose drift between re-acquires. If nothing moved, re-photographing cannot add information — it only adds 2-3 s per miss.

The same node also returns every match in the picture. When the belt presents two parts at once, one acquisition yields both poses, and keeping multiple picks from one image shows how to hold them as separate picks instead of re-triggering. Reusing one acquisition for several downstream reads is the same idea one level up; the image register reuse pattern for multiple part picks shows the controller-side version.

What you need

• A wrist camera, or one fixed camera looking down at the belt.
• Vision software whose matching tool accepts several taught models in one locate node and reports a class with the pose.
• One taught model per shape; for regular outlines such as square, triangle and star, parametric teaching — pick the shape family, set one dimension — is faster to teach and more stable than a pixel template.
• One sort destination per class plus a reject station for the no-match case.
• A color sensor only if the printed form carries color; shape alone is a mono job.

Set up the classify-then-sort step

1. Fix one snapshot position. Frame the part with 10-20% margin so any rotation stays inside the picture. If one position cannot cover every orientation, add positions as in the multiple snapshot positions guide and loop through them.
2. Set one exposure for all classes. Matte printed blocks share an exposure easily. If a shiny and a matte type genuinely need different exposure, alternate two exposure times per trigger instead of adding locate nodes.
3. Teach every shape inside one multi-class locate tool. Parametric teaching suits regular outlines; when part sizes change per batch, teach one model per batch rather than one per size.
4. Leave all models in that single node. The node returns the winning class plus pose. Splitting models across nodes quietly rebuilds the sequential chain you are removing.
5. Map each class to its sort branch. Keep one class-to-destination table, so a fourth shape means one new model plus one map row.
6. Write the no-match branch. Reject lane, one re-trigger after a fixed delay, or an alarm. A program that idles on a failed match is the most common stall.
7. Read all matches from the same picture. If the belt can present several parts, take every returned pose and pick them in position order.
8. Time it. Run 20 or more parts in mixed order and log class plus per-cycle vision time; hold the worst case at or under 3 s, and confirm the poses survive rotation before you trust them.

Worked example: three shape classes on a randomly fed belt

Inputs. Three classes — square, triangle, star — arriving in random order, as the job specifies. 2-3 s per picture-plus-search on a wrist-camera locate node, the working figure from the first section. 2-3 s for one acquisition plus one multi-class search over the three models, the design budget for the single-image step. The arithmetic uses the 2.5 s mid-point, with the bounds shown beside it.

Rule. A per-type chain costs attempts × t_node, with attempts at (N + 1) / 2 on average and N at worst. The single-image structure costs one pass, whichever class arrives.

Arithmetic.

• Worst case, per-type chain: 3 × 2.5 s = 7.5 s (bounds 3 × 2 s = 6 s to 3 × 3 s = 9 s)
• Average, per-type chain: attempts = (3 + 1) / 2 = 2, so 2 × 2.5 s = 5 s (bounds 4-6 s)
• One image: 2.5 s per part (bounds 2-3 s)
• Saving: 7.5 - 2.5 = 5 s per part at worst; 5 - 2.5 = 2.5 s on an average draw
• Vision-limited throughput: 60 s ÷ 9 s ≈ 6.7, about 7 parts/min before; 60 s ÷ 3 s = 20 parts/min after

Result and decision. The classify pass lands near 2.5 s against a 5 s average and up to 9 s for the chain — about 2.5 s saved per part on average, up to 6 s at worst. Keep the single-image structure while the pass stays under the break-even (N + 1) / 2 × t_node, which is 5 s here; at 2-3 s you carry 2-3 s of headroom. Re-time after every new model, and if the pass ever crosses 5 s for this job, split the flow upstream or move classes to a second station.

When one image per cycle is the wrong answer

• Classes that need different light or exposure. A shiny blank and a matte printed block may not share one exposure; alternate two exposures per trigger before giving up on one camera. When classes also need different optics or stations, keep dedicated per-type locate nodes — a five-locate-node structure for camera part location is the pattern for jobs that each need their own locate.
• Shapes too similar for the matcher. If star and triangle still confuse the tool after good models and exposure, shape matching has hit its ceiling; train a classifier on the same image instead. The AI vs rule-based smart camera comparison sets out that choice.
• A model list that keeps growing. The break-even moves in your favor as N grows — (N + 1) / 2 attempts for the chain — but in most tools the search pass also grows with model count. Measure the pass each time you add a class and hold it under the threshold from the example.

Cameras for the one-image route

The logic runs on any camera that feeds a matching tool; choose by where the matching runs and by what the print carries.

On the device. A vision sensor runs the multi-class locate on board and sends class plus pose to the robot over Ethernet, no PC in the loop. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and an M12 mount. When the printed form carries color, the MV-SC6050C-08M-XBN pairs a 5 MP color sensor with an 8 mm lens and a built-in multi-color light source. For pure shape contrast, mono often separates classes better; the HK-TD032-12-WBN is a 1.6 MP mono vision sensor with a global shutter. The rest of the line sits in the smart cameras category, filterable by shutter, mount and resolution in the camera finder.

On a PC. When the classes need a trained classifier instead of template matching, take the image into a PC. The MV-CU020-90GC is a 2.5 MP color area scan camera on GigE with a global shutter and a C-mount, and the area scan cameras category holds the wider range. Either way, prefer global shutter on a moving belt: a rolling shutter smears a part that moves during the exposure.

On the bench first. Teach and time the models at a fixed station before the camera goes on the robot. A slide-table stand such as the LS-MNT-0040 holds height and focus steady between takes, and the camera stands category covers the other mounting options.

Verify the timing and clear the pre-build checklist

Run the acceptance check before you commit the structure: 20 or more parts in mixed order, with a log of class, pose error and per-cycle vision time. A correct conversion shows one picture per part, every class matched, and the worst-case pass at or under 3 s. Pose accuracy matters as much as speed; the rotation-survival locate setup for robot picking lists the checks that keep one taught model honest across rotation.

Mistakes that cost a day each, most common first:

• Teaching from images at a different distance or angle than the runtime snapshot position — teach at the position you will run.
• Changing exposure after teaching; models and exposure are a pair, so change one and re-teach.
• Models split across locate nodes, which quietly restores the multi-second chain.
• A star-vs-triangle ambiguity that no threshold tuning fixes — teach the distinguishing feature, and if it still fails, that is the classifier case above.
• No no-match branch, so the robot idles on the first foreign part.

Pre-build checklist:

• One snapshot position sees every orientation of every class.
• One exposure serves all classes, or two alternate per trigger.
• All models live in one locate node with a class output.
• The class-to-destination map covers every class plus no-match.
• Worst-case pass sits under the break-even: (N + 1) / 2 × t_node — 5 s for this job.
• Global shutter if the part moves during the exposure.

That is the whole conversion: one picture, one multi-class locate, one branch on the class. More sorting and locate programs sit on the applications topic page; if a shape set resists every structure above, bring the drawings to the contact page and we will look at the classes with you.