The pick isn't the hard part – the timing is
A single robot picking products off a belt and placing them into a container is solved technology today. Delta kinematics, path planning, a clean pick-and-place cycle – you can get that reliably right. It only gets interesting once one robot can no longer meet the required throughput and you put several robots on one line.
From that moment, the real problem shifts: away from the individual pick, toward coordination. Incoming products have to be distributed across the robots so that none sits idle, none is overwhelmed, and no gap is left in the container at the end. That's not a mechanical problem – it's a software and control problem.
Two belts, two directions: counter-flow and co-flow
In a robot line, two streams typically run side by side: the product stream (the parts to be picked) and the container stream (the trays, cartons or blisters to be filled). What matters is the direction these two run relative to each other.
In co-flow, the product and container belts move in the same direction. The robot can "ride along" for a stretch, and the relative speed between pick and place point is lower – that eases the dynamics, but costs line length and makes assignment over the distance more involved.
In counter-flow, the belts run against each other. Products and containers meet, the relative motion is higher, but you can fill more densely over a shorter distance. The price is more demanding path and timing planning: per product, the robot has a tighter window in which pick and place have to line up cleanly.
Which method fits isn't a matter of taste – what decides the layout is usually the logistics: infeed and discharge, available line length, cycle rate, product weight and robot dynamics. Mastering both cleanly is exactly where experience shows.
Gaps are the enemy: independently controlled transport sections
Products rarely arrive evenly. Sometimes a cluster, sometimes a dry spell. If you simply split this uneven inflow across several robots, the wrong thing reliably happens: the first robot runs flat out, the ones behind get only the leftovers, and gaps remain in the container.
The lever against this is to treat the product belt not as one rigid belt, but to divide it via separation points into several, independently controllable sections. That lets you deliberately compress or spread out the inflow ahead of each robot – every robot gets its share at the rhythm it needs. The result is even utilization across all robots and a gap-free filled container, without any single robot becoming the bottleneck.
Sounds simple, but it isn't: these sections, the product positions and the robot assignment have to line up consistently in every cycle – at full belt speed.
Seeing before you grip
In practice, products are rarely positioned exactly on the belt. A camera captures position and orientation, often on the fly, and tells the robot exactly where to grip. That sounds like a separate building block, but it's part of the same real-time chain: image data, belt position (encoder) and robot assignment have to be merged in the same cycle. A camera value that arrives too late, or isn't cleanly matched to the right belt position, is worthless.
What this reveals about good software
And here's the actual point – one that reaches far beyond robotics. A coordinated robot line only works if the software does three things at once:
- Hard real-time. Assignment, path planning and sensor data run in a deterministic cycle. There is no "mostly on time".
- Structured and maintainable. The state of dozens of products, several robots and belt sections has to be traceable at any moment – otherwise every extension becomes a risk.
- Data-centric. Each product, each robot, each section is best modeled as its own, self-describing data object, not as a loose set of individual variables.
That's exactly the mindset we build automation software from at ASKS: structure, reusability and clean data handling as the foundation – not as an afterthought. Coordinating multiple robots is the most honest test there is: it punishes sloppy architecture instantly and visibly. Master it, and you have a grip on the fundamentals that matter in every other demanding controller, too.
When this is relevant for you
If you're planning a line with real throughput demands – multiple robots or many coordinated axes, tight cycles, fluctuating inflow – then the project isn't decided at the individual robot, but at the coordination layer above it. That's where experience pays off.
If that sounds like your task: talk to us.