TCP sheets own tool zero after a bump. Payload CoG notes own inertia after pick. Safety scanners own people. This cell problem is different: the workpiece never stops, so the robot’s programmed path must ride a conveyor-tracking frame that moves with encoder pulses.
Industrial packages wire a two-channel (quadrature) encoder to the conveyor so reverse motion and vibration do not invent counts. A synchronization switch or vision trigger stamps object presence into a queue. The controller then keeps TCP relative to that object while belt speed changes—including brief stops—provided the arm stays within its dynamic envelope. Vendor application data for linear tracking commonly quotes TCP path accuracy on the order of a couple of millimeters at moderate constant belt speeds when calibration is honest; that number collapses when counts-per-meter are wrong, the encoder wheel slips, or the conveyor base frame was never taught in robot space.
![]()
Calibrate resolution over the longest practical travel: counts divided by measured meters. Guidance in the field often targets several thousand quadrature counts per meter so quantization is not the dominant error; beyond that, robot and cell calibration dominate. Re-check after belt replacement, drive gearbox work, or encoder remount. Vision-guided random placement still needs trigger-to-motion delay compensation—hand-eye alone does not cancel conveyor travel during camera latency. Log dropped objects when the queue overflows or power cycles clear memory; those are process losses, not mysteries.
![]()
If the integrator demoed a static pick and production “added speed later,” you do not have tracking yet. You have hope with a belt.