Adding visual inspection to a robot cell that already picks

You already run a camera-guided pick cell, and quality now wants presence checks, pattern checks and dimensions on the same parts. The clean way to add them is a second, dedicated inspection camera at a downstream station: the pick camera keeps sending part coordinates, and the inspection camera only owes the robot a verdict. This guide gives you the decision, the field-of-view arithmetic for a part that wanders in its nest, the pixel budget for each feature, a trigger handshake that fails safe, and a cycle-time budget worked through at 90 parts per minute.

Keep the inspection camera separate from the pick camera

The guidance camera is calibrated to the robot frame and owned by the motion schedule: it fires, returns coordinates, and the arm moves on, exactly as in a planar vision-guided pick system. Bolting ten measurement tools onto it couples quality decisions to lighting chosen for pose finding and to a field of view sized for gripping. A dedicated inspection camera at a fixed downstream station sees every part in the same narrow pose window, carries its own light, and returns one thing: a verdict. When that camera gets knocked out of alignment, you recalibrate it alone with a single reference target instead of touching the guidance cell. The robot program gains one step: trigger, wait, route the part.

The pixel rules that decide what the camera can inspect

Four sizing rules cover most inline inspections:

• Presence or absence: the smallest feature you must confirm needs at least 5 pixels across it.
• Code reading: plan on at least 4 pixels per datamatrix module or barcode element for a reliable decode.
• Pattern matching: the feature you match should span at least 50 pixels. A smaller template confuses similar geometry, which shows up as template-too-small errors. Loose tolerances on top of that produce the false hits and flipped matches that erode trust in the station.
• Dimension gauging: put at least 10 pixels across the tolerance band. With subpixel edge interpolation, edge repeatability lands near 0.1-0.2 px, so 10 px per band keeps pixel-level error near 2% of the band. Below about 5 px, the reading follows edge quality and vibration more than the part.

Part size, placement spread and these targets set the field of view and the minimum pixel count. The camera resolution calculator below converts a window and a pixel target into that count:

Worked example: 60 × 40 mm bracket dropped into a nest

The robot places a 60 × 40 mm bracket into a nest with ±3 mm repeatability in X and Y and up to ±5° of rotation, and the camera looks straight down at the stop. Whatever the nest lets move, the tools re-anchor to the part itself: each measurement frame aligns to a reference feature on the part, the same habit as teaching a long thin part by its feature.

Field of view

Add the placement spread on both sides of each dimension, plus the swing of the longest side:

• x: 60 + 2 × 3 + 60 × sin 5° = 60 + 6 + 5.2 = 71.2 mm → specify 75 mm.
• y: 40 + 2 × 3 + 5.2 = 51.2 mm → specify 55 mm.

Assume a 2448 × 2048 array, the common 5 MP layout. Pixel scale is 75 / 2448 = 30.6 µm horizontally and 55 / 2048 = 26.9 µm vertically, so design on the worse 30.6 µm.

Verdicts per feature

Three features clear their rule with margin. The slot fails: 0.10 / 0.0306 = 3.3 px means quantization noise of 30.6 / √12 ≈ 8.8 µm before optics and edge quality add their share, and no algorithm tunes that away. The window is too large for the tolerance, not the camera.

The fix: clamp and shrink the window

A clamp at the gauge station removes the placement spread, so the window only has to cover the slot. Mount a second tight camera at an 80 mm working distance; a 1/1.45"-format sensor is about 8.8 mm wide (4:3 aspect, roughly 11 mm diagonal):

Order the nearest catalog focal, 25 mm, and the geometry lands here: magnification 25 / (80 − 25) = 0.455, window 8.8 / 0.455 = 19.4 mm, pixel scale 19.4 / 2448 = 7.9 µm. The 0.10 mm band then spans 0.10 / 0.0079 = 12.6 px, past the 10 px rule with margin, so the gauge reads true on subpixel edges. The lens focal length calculator below runs this same conversion for any working distance and window you try:

Decision: the loose-nest camera at 75 × 55 mm handles presence, patterns and codes; the slot gauge gets the clamped tight view.

Exposure: let the nest settle, then beat the vibration

Trigger the camera about 150 ms after the in-position signal, once a damped steel nest has settled. What remains is vibration; assume 0.05 mm amplitude at 80 Hz. Peak velocity sets the exposure cap:

Half a pixel of blur (15.3 µm at 30.6 µm pixels) is the working limit for gauging and decoding. Presence and pattern tools run well at a 0.5 ms continuous exposure. The datamatrix and the slot gauge get their sharp edges from a 200 µs strobed pulse, where the pulse width is the exposure.

Cycle-time budget at 90 parts per minute

90 parts per minute is 60,000 / 90 = 667 ms per part. Budget the blocking time, the window in which the robot stands still waiting for the verdict:

That leaves 392 ms of margin, so an 80 ms trap-door solenoid overlaps the robot's return move instead of adding to the cycle. If your cell cannot spare 275 ms of dwell, inspect one part behind the arm; the tools are fast enough to keep up when you pipeline acquisition and processing correctly.

How the robot triggers the inspection and reads the answer

Three patterns cover every cell:

1. TCP text exchange. The camera listens as a server; the robot's TCP client sends a one-line trigger and reads back a one-line answer, overall verdict first, then per-tool results for rework diagnosis. Respect the camera's busy state between acquisitions: firing into a busy camera produces the trigger-ready timeouts that look like random failures. Arm a watchdog at 500 ms and treat a missing, late or malformed reply as fail.
2. GPIO. A trigger input and PASS/FAIL outputs commission in an afternoon and cannot hang on a socket; the trade is that no per-tool detail reaches the robot. The GPIO and serial control pattern covers the wiring.
3. Modbus TCP registers. Some vision systems expose the trigger as registers: set Trigger Enable, then pulse Trigger, and the system accepts it only while Online. The two-register handshake exists to prevent a half-set trigger.

Decide by what the robot must do with the answer: verdict only → GPIO; rework routing per defect → TCP text. Both directions travel the same wire as a coordinate stream from camera to robot, and the same timeout discipline applies.

Where the reject goes

The verdict needs an actuator that finishes inside the station window. A trap door in the part chute that opens on reject and drops the part to a quarantine bin is the classic build. A pneumatic pusher after the station works when parts move in single file, and the robot itself can regrasp to a rack when the cell has the reach. Size the actuator against the 392 ms of margin from the budget table; if it cannot finish in time, track the part with part-present sensor counts to a downstream gate. The routing logic for one camera feeding a robot and a reject pusher transfers directly here. One rule is absolute: no answer means no pass.

Light the station so the verdict repeats

False rejects trace to lighting more often than to algorithms. Four habits hold the image steady:

• Shroud the station so shift changes and open doors cannot move the histogram; ambient light variation is the top drift source on bright parts.
• Set exposure and gain manually on day one and leave them; auto modes drift brightness over time and move your thresholds with them.
• Strobe against motion and ambient at once, and keep strobe and exposure from fighting each other; desynchronization shows up as the black bars of a flicker-versus-exposure mismatch.
• If the light must run continuously for operator visibility, closed-loop monitoring holds the LED output flat as it ages.

Pulse the light from a strobe-capable box such as the LS-CTL-0070 — 4 channels, 200 W, RS232 control — and set the camera exposure to the pulse width, per the vibration math above.

Vision sensor, smart camera, or a controller with cameras

Size the hardware to the number of stations and the detail the robot needs back.

One station, verdict only

A vision sensor runs the tools on the device and answers over Ethernet, with no PC in the cell. A sensor such as the MV-SC3050XC-16M-ATN-H — 5 MP, Fast Ethernet, global shutter, M12 mount — is built for exactly this. M12-mount sensors ship with the lens fitted, so the 75 × 55 mm window at 300 mm working distance is a line in the order, not a lens you add later. If the part cannot come to a station, the camera goes to the part: robot-mounted presence checks at several stops run the same trigger-and-verdict loop from the arm.

One device with light included

When built-in light covers the checks, the LS-SMC-0063 is a 1.6 MP smart camera with a 16 mm lens, 60 fps and its own white light: one device to mount, wire and trigger.

Several stations or tight gauging

Move the tools to a vision controller that also drives the lights. The MV-VC2140-128G40-1T pairs an Intel N97 with 8 GB of memory, 3-4 LAN ports, two USB 3 ports and 4 built-in light channels, so it runs several cameras and pulses their lights from its own outputs.

On-device models compared

Within the on-device family, the shutter column decides whether a part that is still settling images cleanly; rolling shutter skews the rows of a swaying part, while global shutter snaps the whole frame at once:

All 3 share: Power supply 24 VDC; Humidity 20% RH to 95% RH (no condensation); Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

For a station where the part has fully stopped, either shutter type serves; if any sway remains at exposure time, choose from the global-shutter rows.

Checks before you order

• Photograph real parts at the four corners of the nest and at ±5° before you fix the field of view; CAD envelopes never show the sway.
• Count pixels per feature on those photos against the rules above; fix the optics now, not after install.
• Confirm the robot can act as a TCP client with a configurable timeout, or plan the GPIO build.
• Measure the real settle time on the nest and re-run the blur math with the measured amplitude.
• Test the worst ambient case: brightest shift, doors open, overhead lights on.
• Time the reject actuator against the station window.
• Order the M12 lens matched to window and working distance together with the camera.
• Run a golden part at every shift start and log its verdicts; two disagreements in a row means something moved.

When the usual answer is wrong

• Gross presence with cycle to spare: if the pick camera has at least 100 ms of spare cycle and the check is a 5-pixel feature, reuse it; keep the inspection as a separate job so quality logic never sits inside guidance code.
• Features inside bores or threads: no station camera sees them; a contact probe settles them faster than any optical path.
• Natural appearance variation: castings, welds and textiles defeat golden-template matching; a learned model on the cameras you already have is the better first step, as in adding AI surface inspection to existing cameras.
• You need coordinates, not verdicts: that is the guidance camera's job; duplicating it at the inspection station doubles calibration work for nothing.
• Prototype first: build the added station in the robot's offline simulator and check reach and timing there; controller options missing from a finished cell can be added to the simulation afterward.

Your next step

Pick the station that pays first, usually the one generating the scrap, and run the field-of-view and blur math on its real part. The smart camera and vision sensor category covers on-device builds; a vision controller takes over from two stations up, and the light controller category supplies the strobe. The camera finder filters by resolution, shutter and mount, and the system configurator walks the chain from camera to light. For a second opinion on the station layout, write to the applications team, or browse the systems topic.