Skip to content
All posts

Why did the robot stop? · Part 1 of 8

It's easy to play an instrument. It's hard to make music.

Gerben Peeters and Senne Van Baelen4 min read

Gerben on stage at Transport & Logistics 2026, in front of a slide that reads "It's easy to play an instrument. It's hard to make music."

A band that is out of sync is obvious to everyone in the room. Which player caused it is not. I opened our talk at Transport & Logistics in Ghent on 23 September with that line, a year after we first showed ROCO at the same fair, because it explains the challenges of an automated warehouse floor intuitively.

A warehouse aisle with racking on both sides and autonomous forklifts standing still in a queue

For example, take the following situation on an automated warehouse floor. Early in the morning, at the start of a new shift, a robot stops in front of a pallet in an aisle at the far end of the warehouse and won’t pick it. The robots behind it queue up. The WMS has no idea anything is wrong, so it keeps sending orders to the same aisle. Orders start running late, and the site manager sees throughput lower than normal. Twenty minutes later an operator frees the pallet by hand, the flow starts again, and everybody goes back to work. Tomorrow it may happen again.

Ask anyone on that site why the robot stopped, and you get a different answer from each of them, or none. That is what this post is about: why it is so hard to understand your robots, even when every one of them works.

Everyone saw a piece of the stop, nobody saw why

The stop, beat by beat, and who saw each part of it, from the robot to the operator

Everyone in that story did their own job by their own rules. The robot refused a load it could not pick safely. The fleet manager kept the robots behind it waiting, and did nothing else. The WMS kept sending orders to that aisle, because nothing told it the aisle was blocked. The site manager read the throughput figures correctly. The automation engineer found the jam on the fleet screen, and the operator cleared it.

Each of them saw a true piece of the stop, and none of them saw the whole. The site manager knew throughput was down that morning, and nobody could tell them why.

The fences came down

For a long time, automation lived behind a fence. A conveyor, a crane or a robot cell did one task, in one place, on a floor nobody else walked on. The world around it hardly changed, so the well-known warehouse automation pyramid was enough: the ERP at the top, the robots at the bottom, each layer passing orders down to the one below.

Autonomous mobile robots took the fences away. They share open aisles with people and forklifts, in buildings where the layout, the pallets and the orders change every week. Passing orders down is no longer enough. The robot needs to know what the building is doing, the WMS needs to know what the robot is doing, and the people need to know what all of them are doing. The pyramid has become a web, where a stop in one place is felt everywhere else.

On the left, the automation pyramid: ERP, WMS, monitoring, fleet control and robots stacked in layers. On the right, the automation web: the robot in the middle, connected to WMS / ERP / WCS, MES / SCADA, the super-users and the building

Every part of that web was bought and tested on its own, and each one does what it promised. But selecting and integrating the best individual systems does not make them the best team players. The robot vendor delivers a robot that drives well, the integrator connects it to the WMS, and the site is left to work out the rest on the floor, one stop at a time.

What is missing is an orchestrator

A site full of the best systems is still not a team. Somebody has to make them play together, and on most sites nobody does. When we look at a stop like this one, three things are missing.

The systems don’t talk to each other. The robot knew why it stopped, the fleet manager knew the robots behind it were waiting, and the WMS knew orders were running late. None of them told the others, so the WMS kept sending orders into a blocked aisle. Each keeps its own record, in its own language, and the problem grows with every robot brand and fleet manager that joins the floor.

The people can’t talk to the robots. The operator walking up to a stopped robot gets no answer from it: the reason sits in a log or a vendor’s screen, written for the engineer who commissioned it. To act, they need a screen and a login they don’t have, and words they were never taught.

And the people can’t talk to each other about the systems. The operator, the engineer and the site manager each describe the stop in their own terms, from their own piece of it. There is nothing they all look at together, so the version that reaches the top is a guess.

So, how do you orchestrate robots?

Over the next weeks we dive deeper into the main pieces that need to be orchestrated, and into what it takes to make them play together. Next week, we zoom in on the robot. Follow Mappalink on LinkedIn to read each post as it comes out.