Robot Conveyor Tracking: Encoders, Trigger Timing, and Moving Coordinate Frames

A robot that picks parts off a moving conveyor has to answer a simple question that turns out to be hard: where will the part be when the gripper gets there? The camera saw the part at one instant. The robot needs it a fraction of a second later, somewhere downstream. Between those two moments the part keeps moving, the belt keeps moving, and timing error can shift the intercept point and cause a missed pick or collision.

Conveyor tracking is the function that bridges that gap. The useful definition goes beyond "the robot follows the belt": it is a chain of encoder counts, trigger events, and a coordinate frame that moves with the product. This article walks through that chain, and through the limits that decide whether tracking works at production speed.

Separate Detection from Interception

The first thing to separate is detection from interception. Detection is knowing where the part is, at the instant the camera or sensor sees it. Interception is getting the gripper to that part, a fraction of a second later, while the part keeps moving. These are two different problems, and a cell can be excellent at the first and fail at the second. Stopping the belt for each pick removes the moving-target interception step; its effect on throughput depends on the complete stop, settle, pick and restart cycle.

For the wider robot-cell issues around loading positions, PLC signals and recovery ownership, see machine tending robot cell planning. Tracking lets the robot work on a moving stream, which is why it matters for high-throughput lines, but it adds timing and frame coordination to the robot-motion and handling requirements.

When a supplier says "conveyor tracking," the buyer should hear "a timing and frame-management problem," and require both the enabled controller feature and the encoder, trigger and frame boundaries to be specified.

Define Encoder and Conveyor Motion Evidence

Tracking starts with knowing where the belt is, and that evidence has to be defined.

A mainland OEM example makes calibration concrete. JAKA's 1.7.2 command guide defines linear-conveyor pulse equivalent as measured travel in millimetres divided by the change in encoder counts, and sets travel direction in the user coordinate system. Its JAKA App 1.7.2 manual, document V08, separately lists conveyor pulse, speed, direction and raw-pulse data in the controller interface table. Use those versioned examples to ask for the calibration and interface record for the quoted controller, rather than copying settings across models.

That is the encoder's job. A rotary encoder on the conveyor drive, or a linear encoder on the belt, reports belt position, and the robot controller converts that into the part's position by relating the encoder count at detection to the encoder count now. Tracking depends on encoder resolution, the mechanical link between measured movement and actual belt travel, acquisition latency and calibration. A drive-shaft encoder will not reveal belt slip by itself, so verify the measured position against the actual conveyor motion over the production speed and load range.

The buyer's task is to pin down what the encoder actually is and what evidence supports it: the encoder type, its mounting, its resolution, and how the belt-to-encoder relationship was established and verified. "It supports tracking" is not an answer to those questions.

Align Triggers, Timestamps, and Coordinates

Under the encoder count sits the trigger and the frame, and both have to be aligned in time.

Define which event establishes the part position: a sensor edge, camera acquisition or another controller event. Associate that event with the corresponding encoder count, then propagate the detected position using subsequent belt motion. Record exposure timing, processing and communication delay, and how any repeatable delay is compensated. Motion during exposure must be assessed with the imaging setup; it is not automatically an uncorrectable position error.

If the system combines timestamps, it needs a common or correctly mapped time base. An event that directly latches the encoder count can establish the reference without requiring every host clock to be identical. Ask the integrator to demonstrate the event-to-position association under the intended speed changes.

Then comes the frame. When the robot tracks a part, it is not following a fixed point in the cell. It is working in a coordinate frame that moves with the belt, so that a pick defined relative to the part stays valid as the part travels. This matters for everything downstream of the pick. A place position defined in the belt frame moves with the belt unless the controller is told otherwise. Name the frame for each motion. A fixed placement station needs a target expressed in its fixed reference; a placement onto another moving conveyor needs that conveyor's reference and synchronization. ABB's IRC5 conveyor-tracking manual, 3HAC050991-001 Revision W, explains a conveyor base frame and a coordinated work-object user frame whose position follows encoder-derived conveyor travel.

Tracking is an established controller capability with distinct implementation packages. FANUC America describes iRVision 2D combined with iRPickTool for detecting randomly placed parts and picking or placing in linear or circular conveyor tracking. ABB's cited manual covers conveyor tracking for IRC5. Universal Robots' conveyor-tracking guide is explicitly scoped to CB3 software 3.8 and later and e-Series 5.2 and later; its SW5.19 linear-tracking reference defines conveyor direction in the robot base frame and an encoder ticks-per-metre parameter. Confirm the controller, software, enabled options and supported encoder/trigger interface in the actual quotation.

The buyer's concern here is not the mathematics. It is that the boundary between "tracked frame" and "fixed frame" is defined for every motion in the cycle, and that any handoff between a tracking robot and a fixed station is explicit about which frame governs. Using a moving reference for a target intended to stay fixed can introduce a placement offset as the conveyor moves. Test that transition explicitly.

Check Tracking Window and Reach

The usable tracking window depends on robot reach and dynamics, sensing and control timing, conveyor motion, gripper operation and part spacing.

The robot has a reachable zone, and a tracked part has to be picked within it. The robot has joint speed, acceleration, and torque limits, and the time available to move from its waiting position to the intercept point depends on belt speed. As belt speed rises, the intercept window shrinks, and past a point the robot physically cannot get there in time, regardless of how good the vision is.

ABB's manual defines a spatial start window, a maximum tracking distance and checks for robot reach. These are distinct from an approved belt-speed range. Specify where tracking may begin and must end, then verify that the available time at each intended belt speed covers interception, gripping and the remaining cycle without exceeding the robot or cell limits.

So the buyer should not accept a tracking claim that ignores belt speed. Ask for the physical tracking zone, start and exit conditions, permitted speed range and demonstrated cycle rate at the specified part spacing. Check reach and dynamics near the zone boundaries and define how the controller rejects an interception that cannot be completed. Put those limits in the acceptance specification.

Handle Stops, Restarts, and Missed Parts

The most revealing questions about a tracking cell are about what happens when a part is not intercepted. Parts arrive late, gates jam, a part is rejected by the vision check, or the robot is still finishing the previous cycle when the next part arrives.

A tracking system needs a defined behavior for each of these. What happens to a part that fails the pick window: does it continue downstream, is it diverted, is the cell stopped. What happens to a part the vision system cannot identify: is it skipped and logged, or does the line halt. What happens when two parts arrive closer than the cycle time allows: does the cell skip and route an unpicked part, buffer it, or reduce the feed rate. After a stop or emergency stop, define how the controller reconciles its queued objects with actual parts and conveyor position before resuming. Re-identify or route uncertain parts according to the recovery plan; do not assume that either automatic reuse or wholesale discard is required.

Each of these should produce a record, so the miss rate is visible. A tracking cell that hides its misses in a downstream scrap bin looks efficient until someone counts the parts.

Validate at Production Variation

The output of this work is a table that follows the tracking chain from detection to pick, and it has to be validated at the production variation the line actually sees, not at one nominal speed.

Use one row per part class or lane, with columns for the encoder and calibration, trigger event and position association, timing-error allowance, frame for each motion, spatial tracking zone, permitted speeds, part spacing, robot and cell limits, and recorded exception response. Test the intended variation in speed, load and arrival pattern. A nominal-speed trial alone does not qualify an operating range; a fixed-speed production process should still be validated against its specified conditions.

Build that table and the conveyor-tracking question becomes specific. The encoder and trigger are named and their errors bounded. The frames are named for every motion. The spatial window, permitted speeds and limiting conditions are stated separately. The exceptions are defined and logged. Require that complete chain to pass at the intended production conditions before accepting the cell. A smooth demonstration is evidence for its tested conditions, not a substitute for the operating envelope.

Make the timing chain visible before a tracking option is quoted. Provide conveyor speed ranges, encoder location and resolution, sensor trigger sequence, robot/controller models, camera arrangement and the PLC or line-control interface. We can help organize the conveyor tracking interface requirements into an open-issues list for your manufacturer and integrator: position reference, time alignment, tracking window, missed-part recovery and which party validates each link. Controller options, field wiring, programming and the production-speed test must be confirmed and performed within the selected implementation scope.