Design a multi-camera board-level rig on one processor

A five-camera robot head looks like five camera choices. It is one. Every module on a board-level rig streams into the same processor, so resolution, frame rate, shutter and power trade against each other across the rig, not per camera. Get the budget wrong and the discovery happens on the bench: frames drop, ports starve each other, or calibration drifts because a bracket flexed. This guide gives you the arithmetic that sizes the rig — total bytes per second, pixels per view, baseline geometry, per-port power — plus the shutter and calibration decisions that keep it usable, with worked numbers you can replace with your own.

Start from one number: total bytes per second

Every camera adds width × height × frame rate × bytes per pixel to one shared pipe. Mono 8-bit counts 1 byte per pixel, 16-bit counts 2, RGB 8-bit counts 3 and packed 12-bit counts 1.5. Sum the cameras first, then look for a processor whose port map carries the total.

Take five 5 MP mono modules at 30 fps in 8-bit — a typical stereo-plus-context layout. Each camera moves 2592 × 1944 × 30 × 1 B ≈ 151 MB/s, so the rig totals 5 × 151 ≈ 756 MB/s. A single GigE link carries roughly 118 MB/s of payload once protocol overhead is paid, so this rig needs five dedicated 1 GbE ports. On USB 3, plan about 400 MB/s usable per port: the same five modules overrun any hub and even a two-port host. The port map on a vision controller is therefore the first spec to check, ahead of megapixels.

The module numbers above are placeholders for yours; the rig total, not the camera count, makes the decision. Three references worth keeping open while you size it: shared bus limits for multiple camera modules on one host, GigE bandwidth planning for six cameras on one switch, and why a USB hub drops camera frame rate.

Spend pixels where the measurement happens

Pixels per view follow from the smallest feature that view must resolve. Three pixels across a feature is the working minimum for a dependable detection; measuring to sub-pixel edges wants five or more. Work down from the feature instead of up from a headline sensor size.

Example: a 1 mm feature inside a 300 × 225 mm field, measured three pixels across. That asks 0.33 mm per pixel, so 900 × 675 px — about 0.6 MP per view. Any module near 1.6 MP covers it with margin for lens fall-off and calibration loss. The MV-CB016-10GM-M-W carries a 1.6 MP global-shutter sensor on GigE with an M12 mount, so one module takes this job and the wide-sensor budget goes to the views that need it.

Frame rate is the other lever, and it multiplies across every camera in the rig. The same five-camera example, re-cut three ways:

Depth quality lives in the stereo pair, so pixels and frame rate go there first; context views exist to find things, and they rarely measure them. Where the field size is fixed and you would rather start from millimetres per pixel, the calculator below runs the same arithmetic from that end.

Match the shutter to every view

Global shutter for anything that moves or feeds stereo. A rolling shutter reads its rows over a few milliseconds; 10 ms is a sound design value. A head yawing at 90°/s then shows 0.9° of twist between first and last row (90°/s × 10 ms), which bends straight edges and shifts every measurement made on that frame. The global versus rolling shutter comparison works through the choice, and a brief flash against a rolling sensor freezes motion where a sensor swap is not on the table — how the flash trick works.

Stereo adds a synchronisation demand: both eyes must expose the same instant, from one hardware trigger or frame-sync line, not from software timestamps. A 1 ms offset between eyes on a platform moving 1 m/s shears the scene by 1 mm, and that shear lands straight in the disparity map as false depth. Specify global-shutter mono modules for the pair and route the sync line before the bracket is designed.

For the eyes, the LS-BCM-0003 pairs a 3.1 MP global-shutter sensor with USB3 and a C-mount. At 8-bit mono its full rate is 3.1 million px × 120 fps ≈ 372 MB/s; treat 120 fps as the burst setting and 30-60 fps as depth-work cruise.

The context eye is a different pick. The MV-CB060-10UM-B is a 6 MP rolling-shutter mono module shipped as a bare board, at home on a mount that rarely moves. Colour on a moving platform is the awkward case; the LS-BCM-0047 carries a 1.3 MP colour global-shutter sensor behind a C-mount for exactly that slot.

Fix the geometry before you calibrate

Two calibrations exist and they fail differently. Intrinsics — focal length, distortion, principal point — come factory-set per module and survive shipping, so read them rather than re-derive them. Extrinsics — where each module sits and points relative to the others — belong to your bracket, and mounting tolerances move them the moment you tighten the first screw. Enter the measured baselines and angles, calibrate the camera groups that see overlapping scene, and leave cameras with no shared view on the entered pose.

Depth accuracy scales with range squared divided by baseline × focal length, so at double the range the same disparity noise quadruples the depth error. Baselines for heads working 0.5-2 m typically land between 50 and 100 mm. A wider baseline buys accuracy at range, but both eyes must still see the object — which is why wide-angle lenses tolerate wider spacing than narrow ones. Keep the baseline rigid to about a tenth of a millimetre; one that can be knocked half a millimetre re-introduces the error the width was bought to remove.

The calibration work assumes the mechanics are finished first. These cover the steps in order: multi-camera extrinsic calibration into one shared frame, extrinsics-only calibration with fixed intrinsics, and calibrating each pair when one camera serves several pairs. On the mechanics themselves: M12 versus C-mount thread sizes, setting height and back focus on an S-mount holder, and designing the housing from maker STEP files so the bracket matches the board before it is cut.

One shortcut removes half of it: a factory-aligned pair on a single board. The LS-BCM-0043 is a binocular module — two global-shutter sensors on one PCB, streaming 1280 × 1024 frames over USB3 — so the intra-pair geometry is fixed at manufacture and one calibration entry covers both eyes. To budget it, use your planned frame rate: at 60 fps in 8-bit mono a 1.3 MP pair moves 1.3 million px × 60 × 1 B ≈ 78 MB/s on one USB 3 line, and the block then drops into the rig like any single camera.

Budget power, ports and heat

Power attaches to ports, not to rigs. IEEE 802.3af PoE guarantees up to 12.95 W at the camera end of a port, PoE+ lifts that to 25.5 W, and a USB 3 port supplies 4.5 W (900 mA at 5 V). Five cameras on PoE-class ports sit inside about 65 W at the ports; add the controller's own draw and any strobed lights on top.

The practical buy is one controller that closes ports, PoE and lighting together. The MV-VC5525-256G70-NN exposes PoE camera ports on a controller with 5+ LAN ports, eight built-in light channels and 32 GB of memory, so stereo sync, strobes and streams share one wiring loom instead of three. Its built-in light channels drive the strobes against each camera's exposure — set that value per camera in your acquisition code, since each head sees different light.

Heat is the quiet third budget. Five sustained streams keep the processor busy continuously, and a sealed head cannot vent the waste heat: bolt the controller to a metal wall of the housing so its case conducts heat out, and keep cable runs short with a service loop at every articulating joint. A flexing-rated Ethernet cable at the joint matters too — a fatigued cable looks exactly like a flaky camera. For USB-fed rigs the port carries power as well as data, so budget both; the bandwidth and power budget for several USB cameras on one host covers the accounting.

When a shared processor is the wrong answer

This rig shape gives every viewpoint a stream and the front pair a depth map. It does not give a fused 360° point cloud; overlapping stereo coverage plus fusion is a different and heavier system. Where the task is one known measurement volume — a bin, a pallet, a depot bay — a packaged 3D sensor arrives pre-calibrated for the volume, and the 3D sensors range includes structured-light and profiler systems that skip the do-it-yourself geometry entirely. The 2D-or-3D decision for conveyor pick and place sorts which side of that line a task falls on.

The other wrong direction is over-building. One camera watching one feature does not need a five-view rig; size the system to the number of decisions it makes per cycle. The board camera evaluation checklist lists what a minimum build must prove.

Checks before you order

• Compute the rig total in MB/s from your real pixel formats — mono, Bayer, bit depth — and match it to a port map with one camera per GigE port.
• Fix shutter per view: global wherever the mount moves or depth is computed, rolling only for static context.
• Sum power per port at 12.95 W PoE, 25.5 W PoE+ or 4.5 W USB 3, then add the controller and lights.
• Pull the module's PCB outline and hole pattern from the maker's STEP data, and design the bracket with back-focus access and cable strain relief.
• Plan the calibration order: intrinsics read per module, baselines measured on the bracket, overlapping groups calibrated after final assembly.
• Check sensor availability and host compatibility before committing — sensor and host matching and hardware revision checks before reordering.

When the totals fit, the rest is mechanics. Match modules in the board-level cameras range by sensor and shutter first, then let the camera finder filter by interface and mount, and start the camera configurator from your worst-case port map. The step-by-step companions live on the cameras topic page, and if a layout fights the budget, talk it through with the applications team before cutting metal.