Speed up wrist camera locate time: where 5 to 7 seconds go

Your robot finishes a place, swings back to the snapshot pose, and then sits for 5 to 7 seconds before the approach to the next part even starts. Almost none of that wait is mechanics: the arm stands still while images, matching and messages make their way through the vision step. This page splits a wrist-camera pick cycle into its seven stages, ranks the five causes of a long locate by how often each turns up, and gives a test and a fix for each. A worked four-part tray shows the per-pick span dropping from 6.8 to 3.5 seconds, with the arithmetic in the open.

Split the cycle before you tune anything

Timestamp six boundaries once and the slow stage names itself: trigger sent, robot at snapshot pose, image ready, result received, approach start, gripper at the part. Every vision platform can print a timestamp at each of those points, either in its own log or in the robot program around the vision call.

The spans assume a desktop-class processor, an Ethernet camera link and a small-parts tray; each section below says what moves its stage. A cell that waits 5 to 7 seconds before every approach almost always has two or three of these stacked: an auto snapshot, a per-pick re-locate, and a couple of waits added while the demo code was written.

Cause 1, most likely: the cell re-locates parts it already found

The symptom is an almost identical wait before every pick, including parts that were in the first image. The test takes one log line per cycle: count locate runs across a four-part tray. Four locates for four parts is this cause, and it is the default behavior of a lot of demo code: pick one, ask the camera again.

The fix is to locate once per snapshot and store the whole pose list. The robot walks the list and only re-images when the scene actually changed: a failed pick, a gripper that shaded the field, new parts placed. The pose-per-part workflow is the same one behind picking a full tray from one snapshot, and its limits on occlusion and stacked parts are in when one wrist camera snapshot is enough.

The saving is arithmetic. At 1.0 s per locate, four runs per tray cost 4.0 s; one pass costs 1.0 s, so picks 2 to 4 run on stored poses and the tray saves (4 - 1) x 1.0 = 3.0 s of locate. The opposite failure, reusing a result after the scene changed, is its own problem: triggering a fresh measurement per pick shows where that line sits.

Cause 2: auto exposure and focus search inflate the snapshot

Here the long wait shows up before the first pick, or it moves as room light changes through the day. Auto exposure usually captures extra frames to probe brightness, and focus search adds a move-capture-evaluate loop; together they turn a 0.3 s snapshot into a 1.5 to 3 s one on a typical camera.

Test: lock exposure, lock focus, set retries to one, and time image-ready again. Then fix the lighting variation that made auto modes tempting in the first place, because a shroud or hood beats an adaptive camera. The drift mechanism, and which auto modes to turn off, are in why image brightness drifts over time; the snapshot stage has a few more known time sinks, worked through in this wrist camera scan-time troubleshooting guide, and the short version lives in reducing wrist camera snapshot time.

Cause 3: the frame spends longer on the wire than on the processor

A 5 MP mono frame is about 5 MB. On Fast Ethernet that is 5 / 11 ≈ 0.45 s of pure transfer; on GigE, 5 / 110 ≈ 0.05 s. A 1.6 MP sensor cuts the Fast Ethernet case to 1.6 / 11 ≈ 0.15 s, which is why small smart cameras and vision sensors tolerate the slower link.

Check the negotiated speed, not the label: a GigE camera plugged into a 100 Mbit switch port runs at Fast Ethernet. Read the link speed on the switch or network card, and log exposure-end to image-ready. Color triples the bytes unless the camera converts on sensor, and compression changes the arithmetic entirely.

For new cells and camera swaps, GigE end to end is the default. A current example is the MV-SC5060XM-08M-WBN, a 6 MP mono GigE smart camera with an 8 mm M12-mount lens; the shop finder lists cameras by interface and resolution.

If the transfer stage logs above 0.3 s per frame, fix the link or drop resolution before tuning anything else.

Cause 4: locate is searching more scene than the task needs

Match time scales roughly with search area and model count. A full-frame geometric search at 5 MP commonly runs around 1 s; the same model inside an ROI the size of the tray footprint, a quarter of the frame, drops to roughly 1 x 0.25 = 0.25 to 0.3 s. A tuned single-model locate on a desktop-class processor sits between 50 and 300 ms. When locate time swings wildly from cycle to cycle, fix reliability before speed, because an intermittent match failure usually traces back to scene content such as glare, low contrast or clutter, as explained in why a wrist-camera locate fails inside the matching call.

Three changes cover most of it: set the ROI to the tray footprint, keep one trained model per part type, and leave coarse-to-fine search on. If the camera's own processor is saturated, so locate time grows as parts enter the frame, run matching on a vision controller instead and let the robot path see only the result; cutting processing load lists the levers in order.

The MV-VC2140-128G40-1T is the Intel N-series entry with 4 built-in light channels; the MV-VC3301H-128G66 steps up to an Intel Core i3 with 8 GB of memory, 5+ LAN ports and the VM6200Pro runtime license included.

All 2 share: Memory 8 GB; Power supply 24 VDC; Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Cause 5: handshakes and fixed waits stacked on the cycle

A vision request is a conversation: trigger, acknowledge, result, verify. Each round trip on plain Ethernet costs 10 to 50 ms, so even a dozen costs well under a second. The seconds live elsewhere: fixed wait instructions of 0.5 to 1 s added to be safe while the demo was written, and poll loops that check for a result on a timer instead of on an event.

Test: log request-sent and result-received, then read the pick routine for wait instructions. Fix: trigger once per snapshot, receive the whole result list at once, and replace every assumed wait with the measured settle time, because 0.3 s measured beats 1 s assumed. Overlapping the vision call with robot motion hides most of the remainder; the pattern is in overlapping vision and motion in the pick request. And if the cell ran fast during teach but not at runtime, the capture path itself differs: stream versus snapshot is usually why.

Worked example: four parts, before and after

The cell: four parts on an open tray, snapshot pose 300 mm from each pick pose, process speed giving an effective 250 mm/s, so each 300 mm move takes 300 / 250 = 1.2 s. Settle measured at 0.3 s.

Before, with every cause active:

After, with one locate per snapshot, locked exposure, GigE and event-based handshakes:

Per tray of four: 4 x 6.75 = 27.0 s becomes 4 x 3.50 = 14.0 s, so 13.0 s saved on every tray. The amortized locate assumes every part stayed visible and undisturbed; when a pick shades the field, re-image before that one pick, which is still far cheaper than re-locating everything. Cutting the search ROI takes the 1.0 s locate to about 0.3 s as extra headroom.

Match the fix to your timestamps

Read the table top down. The first two rows cover most demo cells, and they are also the two changes that cost nothing but configuration.

When the camera is not the problem

If the timestamps put the seconds in travel, the fixes are mechanical: move the snapshot pose closer to the workspace, since a wrist camera needs little room; raise process speed where the cell allows; or cover a tray wider than one field with several snapshot positions, re-imaging between them. If parts overlap or stack, no amount of 2D tuning tells you which part is graspable, because that is a geometry question: feed parts singly or move to stereo and structured-light 3D sensors, with the choice laid out in choosing a vision approach for flat parts. A cobot running at safety-limited speed is a layout decision, and no camera setting changes it.

Habits that keep locate time fast

• Timestamp every stage boundary from day one. "It feels slow" never points at a stage; a log does.
• Run a locked production profile: auto exposure, auto gain and auto focus off, saved as the run configuration.
• Keep one trained model per part type, and the ROI at the tray footprint.
• Re-image on a scene change, not on a schedule: new parts, a failed pick, an occluded field.
• Re-check stage times after any hardware or firmware swap; a driver update can renegotiate a link or add latency.
• Keep the snapshot pose as close to the workspace as the field of view allows; travel is the one stage no vision setting can shorten.

If you are speccing the camera and controller side of a new cell, the build-a-system configurator pairs them with lights and triggering in one pass, and the vision systems topic page collects the rest of the timing guides. For a second opinion on an existing cell, send your stage timestamps through the contact page with the question; they turn a day of guessing into an afternoon of fixes.