One camera for multiple bins: resolution and coordination trade-offs

Two feed bins, two robots, one camera: it is an attractive arrangement when floor space and cabling are tight, and it works — but only when the optics, the resolution and the frame-rate budget all hold up. This explainer shows you how to run those numbers for your own cell: how wide a field of view you actually need, how many pixels each part gets at each bin, what happens when two robots share one frame stream, and how part positions get routed to the right controller. The arithmetic is simple; skipping it is what makes these projects fail.

Decide in this order

Work through four gates before anything else:

1. Coverage: one lens must see both bins fully, sharp to the corners, with a margin for bin edges and calibration targets.
2. Resolution: the smallest part, in the worst-covered bin, must still land enough pixels to locate reliably.
3. Timing: one shared frame stream must refresh both robots' part lists fast enough for the cycle time.
4. Coordination: your vision software must let you split the image into per-bin regions and route each region's results to a different robot.

If gates 1-2 fail, no amount of software fixes it; buy two cameras. If only gates 3-4 fail, the problem is architectural, and articles like vision picking request timing: overlap processing and motion and vision target routing across overlapping robot work areas cover the software side in depth.

Field of view: size the window, not the bins

The camera must cover both bins plus margins. A practical rule is to add 10-15% on every side for bin positioning tolerance, calibration targets and lens vignetting at the corners — the same margin logic explained in calibration target field of view and lens coverage margins.

Say each bin tray is 300 × 300 mm and they sit side by side with a 50 mm gap. The total span is 650 mm; with 12% margins each side you need about 810 mm of horizontal coverage. Overhead, perpendicular to the conveyor, use the tray height plus part scatter as your vertical margin — call it 350 mm covered vertically with margins.

With a 1"-format sensor (about 13.4 mm wide) at a 1,200 mm mounting height, m = 13.4 / 810 ≈ 0.0165, and f ≈ 1200 × 0.0165 / 1.0165 ≈ 19.5 mm — so a 16-25 mm class lens is the right family. Run your own numbers in the lens focal length calculator or straight from the article:

A lens like the LS-FFL-0567 covers a 1.1" sensor at 16-25 MP grade; for a 1" sensor the LS-FFL-0602 matches. Whatever you pick from the machine vision lenses finder, check the image circle against your sensor diagonal, not just the mount.

Pixels per part: the gate that usually fails

Resolution spent on coverage is resolution not spent on detail. Pixels per millimetre is simply sensor pixels divided by covered width:

Worked example with a 20 MP camera, 1" sensor, 5,472 horizontal pixels, covering the 810 mm span:

• px_per_mm = 5472 / 810 ≈ 6.8 px/mm
• A 15 mm part spans about 100 pixels — comfortable for centroid picking.
• A 4 mm terminal or spring spans about 27 pixels — marginal; you would want template matching, good lighting, and no motion blur.
• A 2 mm feature spans about 13 pixels — plan on two cameras.

A common working minimum is 20-30 pixels across the part and 3-5 pixels on the smallest feature you must resolve. Check the bin at the edge of the field, not the centre: corners of the image get less light and slightly worse resolution, and small parts cluster there first.

For hardware, the MV-CS200-10UM fits the worked example above: a 1" sensor at 16-25 MP resolution with a C-mount. If your pixel budget allows less, the LS-CMR-0166 pairs a 1/1.7" sensor at 12 MP (4000 × 3000) with USB3 at 30 fps. Re-run the px_per_mm arithmetic with 4,000 horizontal pixels over the same 810 mm span: about 4.9 px/mm, so the 15 mm part gets roughly 74 pixels — still workable, but the 4 mm part drops to around 20 and the margin thins fast.

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

There is a faster way to sanity-check the sensor side: the camera resolution calculator does the pixels-per-feature arithmetic for you.

Frame-rate sharing between two robots

Both bins live in one frame, so you pay image acquisition once and detect both regions in one processing pass — that is the genuine efficiency of a shared camera. The cost is that both robots draw from the same refresh clock.

At 10 fps, each robot's part list can be at most 100 ms stale. If each robot picks every 1.5 s, that is fine. If both robots pick every 400 ms and each pick should use a fresh image, one shared camera at 10 fps cannot serve them — you would need 5 fps per robot minimum plus headroom for exposure and processing. Rolling-shutter sensors at high resolution can also be slower than the datasheet peak once exposure time grows; the limits are covered in RGB camera frame rate limits: pixel format and exposure and, for trigger-driven schemes, camera hardware trigger frame rate with external pulses.

A useful pattern: one shared overview camera for part discovery, plus the robots re-confirming grip positions from their own data — the layering described in barcode verification before picking with multiple robots applies the same idea for identity rather than position.

Routing one image to two robots

Architecturally the shared camera publishes one frame; the vision job segments it into fixed regions of interest — one per bin — detects parts per region in the bin's own coordinate frame, and writes each robot's position list to its own handshake. Three rules keep this robust:

• Calibrate each bin region separately, so lens distortion is corrected per region, not with one global fit.
• Give each robot its own acknowledgment channel, so a slow robot never blocks the other's picks — the failure mode behind conveyor target acknowledgment near tracking position rollover.
• Handle the empty-bin case explicitly: an empty region should publish an empty list, not a stale one.

Where the vision system hands calibrated coordinates straight to a robot controller, the coordinate conventions matter as much as the detection — calibrated camera coordinates for robot picking works through a real case of that hand-off.

One camera or two: the trade in numbers

The pattern is clear: doubling the field of view with the same sensor halves pixels per millimetre. Two cameras win once parts are small or cycle times are short; one camera wins on parts per image, cabling and a single calibration session.

Checks before you order

• Measure the real span, including bin-exchange tolerances, then add the margin.
• Compute pixels per millimetre for the smallest part in the worst bin.
• Confirm the lens image circle covers the sensor's full diagonal.
• Verify the camera's frame rate at your exposure time, not at the datasheet's best case.
• Confirm your vision software supports per-region routing to two robot controllers.
• Plan the mounting: a camera 1,200 mm overhead needs a rigid stand, not a bracket on the guarding. The camera stands category includes column stands for exactly this; the LS-MNT-0040 is a professional slide-table type at a 700 mm working height for smaller set-ups.

If you are still weighing options, the camera finder filters by sensor format, resolution and interface, and the system configurator walks camera, lens and stand in one pass. For picking cells similar to this one, sorting conveyor camera selection: pixels, speed and blur covers the moving-part version of the same arithmetic.

When the one-camera answer is wrong

Three situations reliably break it. First, parts under about 5 mm at bin distances beyond a metre: the pixel budget collapses before the software can help. Second, cycle times that demand a fresh image per pick from both robots at once — the shared frame rate becomes the bottleneck. Third, bins that must move or be swapped independently: a fixed shared view locks your mechanical layout. In each case two smaller cameras, each with its own trigger and region, cost less grief than one large sensor pushed past its limits.

Short checklist

• Span measured, margins added, field of view computed.
• Pixels per part verified for the smallest part at the worst bin.
• Lens image circle ≥ sensor diagonal.
• Frame rate at real exposure time ≥ 2 × per-robot pick rate.
• Per-bin calibration and per-robot routing confirmed in software.
• Rigid overhead stand specified.
• Empty-bin and region-rollover behaviour tested.

Run the numbers, then pick the camera count the numbers recommend — not the other way round.