System designExplainer

Single camera inspection routing to a robot and reject pusher

Design single camera inspection routing for a robot and reject pusher using item IDs, encoder positions, separate queues and verified outputs.

LumaSpec Vision10 min read Share on LinkedIn

On this page 10 sections
  1. 01Decide whether you need another decision or another observation
  2. 02Give acquisition one owner and distribute results
  3. 03Build a record that follows the physical item
  4. 04Calculate the position budget before choosing hardware
    1. Worked routing example
  5. 05Keep robot targets and reject actions in separate queues
  6. 06Check actuator spacing and the uncertainty budget
  7. 07Choose camera and controller roles separately
  8. 08Know when the single-observation approach is wrong
  9. 09Commission the routing sequence before production
  10. 10Questions

A camera can classify a conveyor item once while separate control logic sends accepted items toward a robot and rejected items toward a pusher. The difficult part is maintaining each item's identity between inspection and action, especially when processing finishes late or a robot misses a pick.

This arrangement suits cells where both destinations use the same inspection decision. It does not prove that a later operation succeeded. You will need to distinguish shared inspection results from genuine post-process verification, then check whether your acquisition software, tracking system and output hardware support the proposed architecture.

Decide whether you need another decision or another observation

Single camera inspection routing uses one observation to make a quality decision, then distributes that decision to different destinations. The robot receives eligible targets. The reject mechanism receives items assigned to rejection. Neither destination needs to acquire the original image independently.

Post-process verification answers a different question: what happened after an operation? An upstream image cannot show whether a robot removed the item, whether assembly succeeded, or whether a pusher actually cleared the belt.

Requirement Can the original inspection serve it? Additional requirement
Classify an item and choose its destination Yes, if the inspection provides the required information Identity tracking and supported routing logic
Send accepted items to a robot and rejects to a pusher Yes, with suitable controls Separate destination queues and position-based scheduling
Confirm that a robot removed an item No A new observation or suitable presence confirmation
Inspect a feature created during processing No A new image showing that feature
Confirm that rejection succeeded No Downstream observation appropriate to the failure being detected

Sometimes the same physical camera can make a second observation after an indexed move or return cycle. That is still another acquisition, with different visibility and timing requirements. A downstream camera is often more practical on a continuously moving conveyor.

Give acquisition one owner and distribute results

Do not assume that a robot application and a pusher controller can both open the same camera. Discovery, parameter access and image streaming are different capabilities. Even when multiple connections are possible, their ownership and configuration rules need checking.

A clearer architecture gives acquisition to one supported application or device. That owner triggers the camera, receives the image, runs inspection and publishes a structured result. The robot interface and reject scheduler consume those results rather than competing for image acquisition.

The result might contain an item identifier, classification, measured pose and capture encoder count. Its communication method depends on the documented interfaces available in your equipment.

For host-based inspection, compare area scan cameras. For on-device processing, consider smart cameras and vision sensors, but check the actual inspection tools, result fields and communication capabilities before selecting a model.

The distinction matters more than the camera connection count: one image source can support several result consumers without granting each consumer camera control.

Build a record that follows the physical item

A pass/fail bit alone is insufficient when several items occupy the conveyor. Each result needs an identity that remains attached to the same physical object until its final disposition.

A useful item record contains:

  • Item ID: unique within the active tracking session.
  • Capture position: the encoder count associated with exposure.
  • Capture time: useful for diagnostics and detecting stale records.
  • Classification: accept, reject or unknown.
  • Location and pose: sufficient for the destination that needs them.
  • Destination: robot, reject station or a defined exception path.
  • State: awaiting result, queued, requested, confirmed or expired.
  • Recipe and session identity: prevents old results entering a new production run.

Associate the encoder position with image exposure, not with inspection completion. Otherwise, variable processing latency becomes a variable position error. Check the documented relationship between the trigger, exposure event, encoder latch and any timestamps.

Before a result exists, the control system should already know that an item requires a decision. A result deadline can then identify missing inspections. Without that expectation, a missed trigger may leave no record to reject or investigate.

Late or duplicated messages must not create another physical action. Match updates by item ID, reject incompatible session identifiers, and make repeated commands safe to process without repeating the action.

For the problems caused by old observations entering current tracking, see conveyor scene timing and stale pick data.

Calculate the position budget before choosing hardware

For a conveyor moving in one direction without significant slip, encoder displacement estimates the distance traveled since capture. The following relationships are useful starting points:

travel distance = (current count - capture count) / counts per unit distance remaining distance = station distance from capture - travel distance constant-speed time to station = remaining distance / conveyor speed output lead distance ≈ conveyor speed × effective actuator delay command count ≈ capture count + counts per unit distance × (station distance - output lead distance)

The time and actuator-lead calculations assume approximately constant speed over the relevant interval. Encoder tracking handles changing conveyor position, but it does not remove a pusher's mechanical delay.

Worked routing example

Assume these application values, independent of any particular product:

  • Conveyor speed: 500 mm/s.
  • Encoder scaling: 10 counts/mm.
  • Robot pickup window: 450–650 mm after the capture location.
  • Reject contact position: 1,000 mm after capture.
  • Inspection latency: 80 ms.
  • Effective delay from output command to reject contact: 40 ms.

The item moves during inspection:

inspection travel = 500 mm/s × 0.080 s = 40 mm

The item enters the robot window after:

window entry time = 450 mm / 500 mm/s = 0.900 s result-to-window interval = 900 ms - 80 ms = 820 ms

That interval is not entirely available for robot motion. Communication, target acceptance, motion planning and the robot's approach requirements must fit inside the actual picking schedule. The physical window lasts:

window duration = (650 mm - 450 mm) / 500 mm/s = 0.400 s

For the pusher, compensate for its effective delay:

lead distance = 500 mm/s × 0.040 s = 20 mm command position = 1,000 mm - 20 mm = 980 mm command count offset = 980 mm × 10 counts/mm = 9,800 counts

Schedule the command relative to the item's capture count. Do not start an arbitrary travel timer when inspection finishes, because result latency can vary.

For a coordinated multi-destination system, the encoder-sharing guide explains related position-reference concerns. The picking request timing guide addresses the robot-side scheduling budget.

Keep robot targets and reject actions in separate queues

Maintain one authoritative item record, then create destination-specific queue entries that reference it. The robot queue needs pose, eligibility and pickup-window information. The reject queue needs the actuation position and the item's current disposition.

The queues should not independently decide ownership. A central state transition commits the destination so that routine updates cannot assign the same item to both actions.

Robot acceptance of a target is not proof that the item left the conveyor. Define the distinction between target received, pick attempted and removal confirmed. If failed picks must reach the reject station, retain their tracking information until the supported confirmation event occurs.

A failed-pick transfer requires enough distance for failure reporting and reject scheduling. If the item has already passed the pusher's command position, a software reassignment cannot recover that opportunity. The cell needs a documented alternative, such as stopping production or using another containment route.

Define exception handling for:

  • Inspection timeout or an unknown classification.
  • A robot target that expires before pickup.
  • Lost communications or a restarted application.
  • Encoder discontinuity, belt reversal or tracking-reference loss.
  • A reject output that is unavailable or not acknowledged.

Unknown quality should not silently become acceptance. Depending on the process, the appropriate response may be rejection, segregation or a controlled stop.

Check actuator spacing and the uncertainty budget

A pusher must complete its action and recover before the next relevant item arrives. Average production rate is not enough; adjacent rejects are often the limiting case.

At a pitch of 100 mm and a conveyor speed of 500 mm/s:

arrival interval = 100 mm / 500 mm/s = 0.200 s = 200 ms

If an illustrative actuator needs a 60 ms active interval followed by 90 ms recovery, its total cycle occupies 150 ms. That leaves 50 ms before the next item at that pitch. Validate the complete mechanism, including load, pressure variation, output timing and item interaction.

Timing uncertainty also becomes position uncertainty:

position uncertainty from delay = speed × delay uncertainty 500 mm/s × 0.005 s = 2.5 mm

Suppose image-location uncertainty is ±1 mm, actuator-delay uncertainty contributes ±2.5 mm, and belt slip contributes ±2 mm. A conservative worst-case sum is ±5.5 mm. Do not substitute a statistical combination unless the error assumptions justify it.

Encoder resolution is only one contributor. A scale of 10 counts/mm gives 0.1 mm per count, but that does not establish overall placement accuracy. Compare the full uncertainty budget with the item's usable contact area and neighboring-item clearance.

Choose camera and controller roles separately

Choose the imaging hardware from the inspection requirement first: feature visibility, contrast, motion behavior and required detail. Then choose the control architecture from tracking, communication and output requirements.

The LS-CMR-0395 is a monochrome, global-shutter GigE area scan camera with a C-mount. Consider it as an acquisition candidate for a host-based architecture, subject to the inspection's optical and performance requirements.

Area scan camerasGigE area scan camera, LS-CMR-S29 series with CMOS sensor, 1.3 MP, GigE, Mono, 4μm pixels (LS-CMR-0395)LS-CMR-0395
Sensor format
1/2.7"
Interface
GigE
Resolution
Up to 3 MP
Shutter
Global
$299.00View partBuild a system with it

The MV-SC3013XM-12M-ATN-H is a monochrome, global-shutter vision sensor with a GigE interface. For an on-device architecture, verify the required inspection tools and result interfaces rather than assuming they follow from the interface specification.

Smart cameras & vision sensorsHikrobot MV-SC3013XM-12M-ATN-H 1.3 MP mono vision sensorMV-SC3013XM-12M-ATN-H
Interface
GigE
Resolution
Up to 3 MP
Sensor format
1/1.45"
Shutter
Global
$1,809.00View part

Use the camera finder to compare imaging options. Neither a camera's interface nor its shutter type establishes support for shared access, item queues or robot routing.

A dedicated control architecture may also involve vision controllers. The MV-SVC2506-16G60-128G is a controller candidate to evaluate against the required software and integration interfaces, not evidence that this routing sequence is supported automatically.

Vision controllersHikrobot MV-SVC2506-16G60-128G 4 camera GigE ports, 1 configuration GigE port, 1 communication GigE port, 6100pro encryption supportedMV-SVC2506-16G60-128G
LAN ports
5+ LAN ports
USB 3 ports
2 USB 3 ports
Light outputs
4 built-in channels
Memory
16 GB
Price on requestView and quoteBuild a system with it

Confirm licensing, camera compatibility, encoder acquisition, result messaging and output scheduling in the applicable documentation. For acquisition timing questions, consult hardware triggering with external pulses.

Know when the single-observation approach is wrong

Add another observation when the decision depends on something that changes after the first image. Examples include a newly inserted component, a disturbed label, an exposed underside or the result of a reject action.

Tracking can also become inadequate when items slide, rotate, collide or transfer between conveyors after inspection. An encoder measures conveyor motion, not necessarily each item's motion. A downstream locating image may therefore be needed even when no new quality feature requires inspection.

Another camera can improve visibility, but it does not automatically solve missing IDs or ambiguous ownership. Its results still need association with the correct item and a defined relationship to earlier decisions.

Conversely, adding a camera solely to give another consumer access to an unchanged classification may add unnecessary acquisition and synchronization work. A documented result-distribution interface can be the better answer.

When evaluating camera count, list every required observation and the event it proves. Separate those observations from the number of applications that need the resulting data.

Commission the routing sequence before production

Use a commissioning checklist that exercises identity and failure handling, not just successful inspection:

  • Verify capture association. Confirm that each expected item receives the correct image and capture position.
  • Alternate classifications. Run accept–reject–accept patterns and confirm both queues preserve item identity.
  • Test consecutive rejects. Challenge the pusher at the minimum permitted item spacing.
  • Delay a result. Confirm that a late message cannot schedule an action for the wrong item.
  • Duplicate a result. Check that retries do not create another target or output pulse.
  • Simulate a missed pick. Verify the documented transfer or containment policy before the reject deadline.
  • Change speed within the approved range. Recheck actuator compensation and pickup-window availability.
  • Exercise stop and restart. Invalidate stale records and re-establish the tracking reference through the supported sequence.
  • Log each transition. Record item ID, capture count, destination, command position and confirmation state.

For restart coordination, use the conveyor vision startup synchronization guide. Keep commissioning tests within the machine's approved operating and safety procedures.

Before ordering, prepare a timing sketch, interface list and observation checklist. Start with the camera configurator, or send the proposed capture, pickup and reject arrangement through application support to review which hardware roles fit your requirements.

Questions

Can one camera supply inspection results to both a robot and a reject pusher?

One acquisition can supply the classification used by both destinations when supported control software distributes the results. The camera does not necessarily need connections from both controllers. Reliable operation depends on associating each decision with its physical item and scheduling the destination action before its deadline.

Does reusing an inspection result count as post-process verification?

Post-process verification requires evidence collected after the operation being checked. Reusing an earlier image only repeats the earlier decision. Depending on the requirement, confirmation might come from another image or a suitable presence sensor, but the observation must actually demonstrate the required outcome.

Can two applications connect directly to the same camera?

That depends on the documented camera and software architecture. Network discovery does not establish permission for simultaneous acquisition or parameter changes. Prefer a supported acquisition owner that publishes results, unless the documentation explicitly describes and supports the required multiple-client arrangement.

What should happen when the robot fails to pick an accepted item?

Choose the missed-pick policy before commissioning. Possible responses include tracked reassignment to a downstream reject station, segregation or a controlled stop. Reassignment only works if the system detects failure while sufficient travel remains, and if the original item's position is still known.

Is an encoder necessary for a downstream reject pusher?

A timer may be adequate for a validated constant-speed arrangement with sufficient positional tolerance. Encoder tracking is generally more suitable when speed changes or stops occur. Neither method corrects item slip automatically, and a delayed actuator still needs compensation and an uncertainty allowance.