Master-slave architecture for vision guidance: who runs the pick

Two integration models exist for 3D vision-guided picking, and the choice decides who owns the pick cycle for the life of the cell. In the standard-interface model the robot program is master: it calls the vision system for a pose, then moves on paths taught in advance. In the fully controlled model the vision controller is master: it plans collision-free trajectories from the point cloud and the robot executes them. The right answer falls out of three numbers you already know — takt, pick depth and the number of vision calls your geometry forces. This comparison runs the per-pick latency arithmetic, lines the two models up in a table and ends with a decision rule per cell type.

The decision: who owns the pick cycle

The master decides what happens next; the slave executes. A pick cell has exactly one master, and much integration pain comes from cells where two programs both act like it.

Robot master — the standard interface. The camera vendor supplies a communication program that runs on the robot controller and exposes a fixed command set: trigger a capture, fetch the result. Your robot program keeps every motion decision, calls for a pose when it needs one and applies the returned offset inside its own calibrated frame. That frame bookkeeping is where most position errors hide; a guide to handling user-frame offsets in robot vision guidance walks through it. To the rest of the cell, vision behaves like a smart sensor on the network.

Vision master — fully controlled. The vision software holds the robot's kinematic model, tool data and collision envelope, plans a trajectory from the live point cloud and streams motion commands. The robot runs a thin receiver program and reports back. Trajectory authorship moves out of the robot program, which is why this model needs the kinematic and collision data loaded and kept current on the vision side.

Both models use the same sensors and the same hand-eye calibration. What differs is where the pick logic lives, how many vision calls a pick costs, and which program you retune when a pick misses.

The latency arithmetic

Every vision call costs capture plus compute plus the network hop, and you pay one settle move per imaging pose:

Worked assumptions: 20 ms exposure, 180 ms of point-cloud processing and pose search, 5 ms round trip on a dedicated GigE switch, 250 ms for the robot to reach an imaging pose and settle. Exposure climbs on dark or shiny parts and compute climbs with point density, so substitute measured values before you commit a takt to these results.

t_call = 20 ms + 180 ms + 5 ms = 205 ms

Cell A: robot master, singulated parts, 2.0 s takt

One call per pick, no in-bin verification:

Cycle = 250 + 205 + 600 + 700 = 1,755 ms. Output = 60,000 ÷ 1,755 ≈ 34 picks per minute, against the 30 the takt allows. The vision block costs 455 ms, or 23% of takt, and the cell runs.

Cell B: 400 mm deep bin, 4.0 s takt, both architectures

Parts lie anywhere from the top layer to 400 mm down, with neighbours blocking straight approaches.

Robot master needs capture, approach verification and grasp verification — three calls, three imaging moves. Overhead = 3 × (250 + 205) = 1,365 ms, which is 34% of takt. Cycle = 1,365 + 600 + 700 = 2,665 ms, about 22 picks per minute against the 15 the takt allows.

Takt still holds. The failure is coverage: every verify pose is taught, and an approach taught with 60 mm of clearance above the top layer has no valid twin 400 mm down between standing parts. Verifications start failing as the bin empties, and each one costs a re-cycle of about 2.7 s. The architecture breaks on coverage, not on latency.

Vision master on the same bin: the fixed sensor captures the scene once and the planner streams a path. Overhead = 200 ms capture + 180 ms plan + 5 ms stream = 385 ms, 9.6% of takt. Cycle = 385 + 1,300 + 700 = 2,385 ms, about 25 picks per minute. The planned multi-waypoint path costs 1,300 ms against 600 ms for a straight taught approach — the price of collision-free motion through clutter — and it stays valid from a full bin to the last parts because it is re-planned from the live cloud each pick.

The decision numbers: robot master when the call count is 1 and taught clearances cover the whole reachable pick volume; vision master when calls reach 3 or grasp height spans more than roughly 100 mm. Keep vision overhead under about a quarter of takt; past that, retries consume the margin faster than planning adds time.

Choose robot master (the standard interface)

Singulated parts. Conveyor, presentation grid or feeder: the part stands alone, one call returns a pose, and the taught approach is always valid. A projected structured-light camera does this job:

Shallow layers. One- or two-layer totes keep every pick inside a teachable clearance band. A full tray can also go in one snapshot instead of per-part calls — multiple object detection in one snapshot: pick a full tray per cycle drops the call count below one per pick.

Profile-driven picks. Where the pose must come from a swept profile rather than a snapshot — connector pins, machined features, seam starts — a 3D laser profile sensor delivers the geometry:

PLC-driven cells. A standard interface is easy to serve from a PLC-controlled line, provided the result is fresh: re-trigger per pick so a buffered pose never drives the gripper — vision result stale every cycle: trigger a fresh measurement per pick shows the pattern.

You own the robot code and want to keep it. Offsets, retry strategies and approach variants stay in code you control — variable pick approach offsets for vision-guided picking is the working pattern — and the robot's jogging, error recovery and safety logic stay untouched.

Choose vision master (fully controlled)

Deep bins and clutter. Grasp height spans hundreds of millimetres and neighbours block every straight approach. Per-pick planning from the point cloud is what keeps the call count at one; bin picking non planar parts with 3D vision guidance shows what that planning has to handle.

Dense geometry in, paths out. A planner is only as good as its cloud. A laser galvanometer stereo camera scans dense geometry for exactly this role:

Check cloud quality before architecture: thin clouds on small, dark or shiny parts break matching and planning first — 3D matching small parts: why thin point clouds fail and the fix.

Adding part variants. Planned picks match against a model, and 3D point cloud template matching and deviation measurement is the core operation — a new variant means a new model, not a re-teach on the robot.

Compute that stays on the floor. The planner needs camera and light wiring in the same chassis as the processing. The MV-VC5525-256G70-NN carries 8 built-in light channels, PoE camera ports and 32 GB of memory, so cameras, lights and planner share a chassis:

Browse the racks in the vision controllers category; the sensor side lives in 3D sensors, with the camera finder narrowing the choice.

Hybrid cells: split by station

Large cells split by station, not by doctrine. A staged kitting station runs robot master, the bin station beside it runs vision master, and both report up to the same PLC. The one rule that keeps this sane: one master per robot. Two programs that both command one robot produce the classic failure — a cycle that hangs waiting for the other program's permission. Where the boundary between vision authority and gripper control sits in a mixed cell, vision system and robot gripper control architecture: who drives what maps it station by station. More architecture reading sits on the systems topic page.

Commissioning checks before you commit

• Define the handshake on paper first. Request strings, result fields, units — millimetres, degrees, quaternion or Euler — and a timeout. The usual month-one failure is a unit or frame mismatch, not vision quality.
• Set the retry rule now. Decide what a missed or stale call costs: re-trigger, skip the part or stop the line. Retry logic added after commissioning is where double-picks come from.
• Calibrate hand-eye once, with one method. Both architectures live by the camera-to-robot transform; a vision master plans directly in robot coordinates, so its accuracy ceiling is that transform.
• Prove the network before the cell. Dedicated switch, fixed addresses, no office traffic on the wire. If the camera hangs off the robot controller's own port, a guide to connecting a GigE Vision camera through a robot controller shows the set-up end to end.
• Test full, half and near-empty. Coverage failures appear as the bin empties, never at commissioning with a fresh full bin.
• Confirm robot-side compatibility before hardware ships. 3D camera robot integration: check compatibility lists the interface and firmware questions to ask first.

When the usual answer is wrong

Folk wisdom fails in both directions.

Deep bin does not always mean vision master. Stiff parts singulated upstream make a robot-master cell with a wrist-mounted sensor the stronger layout: the gripper sees at the pick pose, occlusion disappears and the taught paths stay. The one-snapshot limits are measured in wrist camera bin picking limits: when one snapshot works — read them before paying for a planner. Singulate first, plan second.

Robot master is not always simpler. Fully controlled shifts path authorship into software that already knows the scene. When the paths are hard and robot programming hours are scarce, the vision-master route can commission faster despite the heavier vision-side set-up: you trade robot code for model and kinematic configuration.

Staged, known geometry flips it back. Palletizing boxes are the textbook robot-master case — vision sizes and locates, the robot owns placement — and the 3D vision robot palletizing integration checks apply on either architecture.

The decision per cell

Put the three numbers — call count, overhead share, coverage band — against your cell and the answer falls out:

Run the Cell A arithmetic on your own takt first; most singulated cells close in minutes, and the deep-bin case usually closes just as fast.

If your numbers land between the rows above, send the pick depth, takt and part family through the contact page and we will run the arithmetic with you.