Wrist camera located object count: loop until the last part is picked

A wrist camera over a vibrating table often sees several parts in one shot, but the program only benefits if it reads how many. Most picking programs ignore that number: they pick one part, restart the table and re-locate, which pauses the feed after every part and lets the remaining parts drift away from the poses the camera just taught. This guide shows you how to read the located object count from the locate result, loop one pick per pose until the list is empty, and switch the table on only after the grasp that empties it. It also covers the field-of-view check that keeps the count honest and the failure branches that keep the cell from stalling.

What the locate result holds

Every locate node writes more than one pose. Its result variable carries one entry per matched object, and the length of that list is the located object count. On the pendant it shows up as a variable whose name starts with f_ followed by digits; the digits tell apart different locate instances, and the variable holds the match count together with one pose per match.

You can consume that list two ways. Your program reads the length and picks entry by entry, which is the pattern below. Or the node consumes the list itself: the camera manual's model-configuration chapter describes the camlocate node as a loop that keeps going until every located object is processed, in which case no counter of your own is needed and the table gate simply moves to the node's boundaries.

Either way, check one setting before you rely on the number: the model's maximum match count. It caps the list, so a cap below your worst-case pile returns a short count and fires the last-part logic early. Picking everything one snapshot found in a single cycle is a pattern in its own right — multiple object detection in one snapshot: pick a full tray per cycle works through the tray version.

What you need

• A wrist-mounted camera whose locate exposes its results as a variable you can read.
• A digital output that switches the vibrating table, driven from the robot controller's I/O.
• A grasp check — a vacuum pressure switch or a part-present sensor — so only a confirmed pick consumes an entry.
• Access to the pendant's script or graph view, to read the list length.

The locate does not have to run on the robot. Both sensors below carry the inspection on the device, so the count and the pose list live on the camera and the robot program only reads results.

The first pairs a 1.6 MP color sensor with a 12 mm manual-focus lens on Fast Ethernet; the second is a 6 MP mono smart camera with an 8 mm M12-mount lens on GigE, which buys extra pixels when parts sit close together. When the locate moves off-camera instead — several cameras, custom logic, a controller already linked to the robot — the counting loop runs on a vision controller.

The MV-VC2140-128G40-1T gives that program 3-4 LAN ports, 2 USB 3 ports, 4 built-in light channels, an Intel N-series processor, 8 GB of memory and 8GB+128G SSD+ 1THDD of storage.

Program the count loop

Teach the model to survive in-plane rotation before anything else: the wrist will not present parts at the taught angle. Vision locate for robot part picking: set it up to survive rotation walks that set-up. Then build the batch around these steps.

1. Switch the table off and wait out a settle delay. Drive the table from a digital output and start the delay at 0.5 s. Raise it until a part photographed before and after the delay locates at the same pose; that photo pair sets the number for your table, part mass and mount.
2. Trigger the locate and read the count. Copy the list length into an integer — call it parts_left — and copy the pose list with it. The next locate overwrites the variable, so read it once per cycle.
3. Handle zero before anything else. If parts_left is 0, switch the table back on, wait one feed interval and jump back to step 1. Count consecutive empty locates and raise an operator alarm after three, so a blocked feed reaches the panel instead of looping silently.
4. Pick entry one. Move to the first pose, grasp, and wait for the grasp-check signal. On a failure, retry the same pose up to three times; if it still fails, re-locate with the table still off rather than counting a part you do not have.
5. Place, then step through the list. After each confirmed grasp, place the part and subtract one from parts_left. While it is still above 0, move to the next entry. The table stays off through all of it: the un-picked poses are only valid while the parts sit still.
6. Gate the table on the final grasp. The grasp that takes parts_left to 0 is the trigger: switch the table on immediately after that grasp confirms, then place the last part. The feed resumes during the place motion, which is exactly the dead time the old program lost after every pick.
7. Close the cycle. Once the last part is placed, switch the table off, wait out the settle delay and return to step 1. The next locate re-counts whatever the feed delivered while the robot was placing.

Worked example: what one snapshot covers at a 350 mm wrist mount

Work the field of view before you teach anything; the counter is only honest if one snapshot sees the whole scatter zone. Example inputs for this kind of cell: mount height 350 mm above the table (a common wrist standoff — measure yours), the compact sensor from the parts rail behind its 12 mm lens, the 1/2.9"-format sensor taken as 5.5 mm wide with 1,440 columns (its 1.6 MP in a 4:3 layout), and a scatter zone of 200 × 150 mm to cover.

The rule in words: the field of view grows with working distance and sensor size, and shrinks with focal length.

Field of view across the table: 5.5 mm × 350 mm ÷ 12 mm = 160 mm. Sensor height is 5.5 mm × 3 ÷ 4 ≈ 4.1 mm, so the snapshot covers about 160 × 120 mm. Pixel density: 1,440 px ÷ 160 mm ≈ 9 px/mm. A 10 mm-wide part then spans about 90 px — taught pattern models stay reliable down to roughly 50 px across the part, so this leaves margin — and a 2 mm gap between parts reads as about 18 px, enough to keep two matches from merging into one.

To cover the full 200 mm zone width instead, raise the mount: 12 mm × 200 mm ÷ 5.5 mm ≈ 436 mm working distance. Density falls to 1,440 px ÷ 200 mm = 7.2 px/mm and the 10 mm part spans about 72 px, still above that floor.

The decision is one of two set-ups: keep the 350 mm mount and fence the scatter to about 160 × 120 mm, or move the mount to about 440 mm and cap the zone at 200 × 150 mm. If parts can land outside the covered window, the count returns short, the parts_left-to-zero branch fires with parts still on the table, and the feed restarts while poses are still in play — the exact drift this pattern exists to prevent.

The same one-snapshot ceiling governs wrist bin picking: wrist camera bin picking limits: when one snapshot works works it through for scattered bins.

Verify the count and the timing

Three checks settle whether the loop is trustworthy.

Run a worst-case batch first. Place the largest plausible pile on the table by hand and run one locate: the count must match the parts visible in the image. If it is short, raise the maximum match setting from the model-configuration chapter before anything else.

Log two values every cycle — parts_left at locate and confirmed picks at cycle end. Over 20 cycles the two totals must match, and the tray count at the end must match the parts fed in. Confirmed picks running short of the count points at grasps failing silently; the count running short of visible parts points at the cap or at overlap.

Time the table-on output against the robot log: it must fall between the final grasp-confirmed signal and the place-complete signal. Anything earlier and un-picked poses go stale mid-batch. For a feeding belt rather than a table, the same gate collapses to a single flag — vision locate with a part detected flag variable: stop the empty belt covers that variant.

Common mistakes that break the count

• Counting a grasp you did not confirm. Subtract one from parts_left only on the grasp-check signal; a swallowed part otherwise strands an entry and the cycle ends one part light.
• Restarting the table while parts_left is above 0. Every remaining pose goes stale the instant the table moves. This is the one mistake the whole pattern exists to prevent.
• Reading the pose variable after the next locate has run. It has been overwritten. Copy the list once, at step 2.
• A maximum-match cap below the worst-case pile. The empty branch fires with parts still on the table. Set the cap above the pile and prove it with a hand-placed maximum.
• Overlapping parts. A locate counts separable matches, not physical parts: two overlapped parts return one entry. Vibration usually separates them; where it does not, loop locate-until-empty instead — batch picking from a tray: loop vision locate until no parts found is that pattern end to end.
• A settle delay tuned once and forgotten. Re-run the photo-pair test after any change to table speed, part mass or mount height; drift shows up first as grasps landing a few millimetres off.

When to skip the count and re-locate every pick

The count pattern buys feed-running time but adds list handling. The simpler alternative is to re-locate after every place, which lets the table run during every place because no pose survives long enough to go stale. The price is one locate plus a settle delay per part.

Choose by share of cycle time. When locate plus settle takes less than about a tenth of the pick-place cycle, re-locating every pick is simpler and costs little. Count from one snapshot when locate time is a real share of the cycle or when parts arrive faster than the robot clears them. And when parts overlap unpredictably, a single-snapshot count misleads — re-locate until the table reads empty instead. Before teaching any of this, run the part through a feasibility pass: can vision locate this part? A feasibility checklist before you teach is the checklist.

Where to go next

Pick the camera by scatter zone and mount room from the smart cameras and vision sensors category; add a vision controller when the locate and counting logic move off the camera. The system configurator matches camera, lens and light to the table once you know the zone size and cycle target, and the applications topic collects more picking patterns like this one.