“The robot stops dead once it reaches the back of the plant, and someone has to go push it back.” This is one of the most common complaints we hear on customer sites. The problem isn’t the robot — it’s the network. And network dead zones are the norm in a facility, not the exception.
The Reality of Factory Network Dead Zones
Metal racks, stamping presses, overhead cranes, rows of machines — all of them are physical barriers to WiFi signal. No matter how densely you deploy access points, there will always be aisles and corners the signal can’t reach. For office devices, a few seconds of dropout goes unnoticed. But for an AMR in the middle of a multi-stop transport task, the instant it drops offline, the task is left hanging in mid-air.
Telling the customer to “fix the plant-wide WiFi first” sounds reasonable, but in practice it’s often unworkable: cabling requires shutting down production lines, new APs require security review, and some areas simply don’t permit additional network equipment. Our conclusion: rather than asking the environment to accommodate the robot, make the robot independent of the environment.
Why Most AMRs Drop Dead the Moment They Lose Connection
Mainstream AMR systems are architected as “brain on the server, limbs on the robot”: a central server (or the cloud) handles task scheduling and issues step-by-step commands, while the robot only executes one action at a time. After reaching point A, where to go next has to wait for the server to say so.
This architecture works fine while the connection holds, but the moment the robot enters a dead zone it falls apart: once the robot finishes its current action, it never receives the next command, so it can only sit idle or report failure. The task is stuck “half done” — the server can’t see the robot, the robot can’t reach the server, both sides are waiting on the other, and the floor operator just sees a robot stalled in the middle of an aisle. The obvious fix is just as blunt: expose the antennas, and use two where one would do. In an age when every other gadget hides its antenna away, robots may be one of the few products that proudly go the other way.
Another architecture straps a tablet onto the robot and sells itself on running fully offline. But the moment the robot moves out of sight, there’s no way left to know its status.
A single-stop task might just barely slip past a dead zone, but a “multi-stop route” is nearly doomed: the more stops, the longer the route, the closer the probability of crossing a dead zone gets to one.
Our Solution: Put the Entire Route Inside the Robot
Sigma flips the model: the instant a task is dispatched, the entire route — every stop, the dwell logic, the confirmation conditions — is written into a single program on the spot and deployed to run inside the robot itself.
Kachaka robots ship with a built-in Playground environment for running user programs (published by the manufacturer Preferred Robotics on kachaka-api). After our Hub pushes the route execution script up over SSH, the roles invert: the Hub is no longer the central controller issuing step-by-step commands — it steps back into the role of an observer, and the route’s progress is decided entirely and autonomously by the script on the robot.
The more important piece: once the robot exits the dead zone and reconnects, the script reports each stop’s arrival and confirmation events back to the host to backfill the record. And if the server restarts on its end, it automatically rebuilds state and marks genuinely interrupted online tasks as interrupted, leaving no ghost tasks behind.
Running a “multi-stop” route under partial-offline, unstable-network conditions — with per-stop confirmation reported back — is an industry first.
With No Network, How Do People and Robots Communicate? Give It a Shake
The approach above solves how the robot gets its commands and reports back, but one problem remains: once it arrives, how does the operator tell the robot, “I’ve taken the goods, you can go”?
With no network, app buttons, web UIs, and wireless buttons all stop working. Do we go back to the old way and bolt a tablet onto the robot? The interface we ultimately chose is a sensor the robot already carries: the IMU. The operator finishes picking up at the stop, gives the robot’s body a shake by hand, the robot detects the shake, and heads to the next stop. When the route is done, one shake sends it home.
This design has several advantages: zero extra hardware, zero pairing setup, zero learning curve — “shake it and it goes” is a single sentence that teaches any line worker. And it’s a purely local, physical interaction, completely independent of network state.
How Do You Tell a Push From a Shake?
The real challenge in implementation is false detection. People on the floor will “push” the robot out of the way, and driving and docking with shelves themselves produce significant acceleration spikes — none of which can be treated as a confirmation signal.
We use a simple but robust algorithm that lets the robot tell being pushed aside apart from being deliberately shaken — and that keeps it from triggering while on the move.
So once the robot is in position, the operator can push it wherever they like, pick things up and set them down, then give it a shake — and off it goes to the next stop.
Takeaway
The offline multi-stop route uses no magic algorithm — just a few pragmatic choices: push the route logic, generated on the fly, down onto the robot itself; let the robot report its own task status; and let the robot’s own sensor decide whether to move on to the next stop.
Facilities won’t re-cable their network for a robot, so the robot has to learn to get the job done where there’s no network.