A robot working in production looks different from a robot in a demo. The working robot does one task, in one place, under conditions that stay the same. The moment something shifts—a part arrives at a different angle, lighting changes, a shelf moves—the working robot often stops. This is not a failure of the robot. It is a failure of the job design.
The robots that keep working are not smarter. They work because the humans around them have made the work stable enough for a machine to do it reliably. This article is about recognizing what makes work robot-compatible, and what doesn't.
The difference between tolerable and intolerable variability
Robots accept some variation. A robot can handle a part that is 2mm off-center. It can work under LED lighting instead of fluorescent. It can pick from a bin where items are roughly—but not perfectly—the same.
But each tolerance has a cost. Wider tolerance means more complex sensing. More complex sensing means slower cycle time, more power, more heat, more things to tune. The robot that can handle anything is slow and expensive and breaks often.
The job that works is one where variation stays within the robot's design window. A parts feeder that randomizes item orientation will break a picking robot. A parts feeder that orients items consistently will keep it running for months.
Variation compounds. If lighting varies by 20% and part color varies by 15% and surface finish changes between batches, the robot's vision system has to account for all three at once. Each layer of variation makes the problem exponentially harder.
The working job isolates what varies from what the robot must perceive. A robot cannot reliably identify different part types if they arrive mixed. But if you separate them into bins first, the robot only has to recognize one type. Suddenly it works.
Environmental stability matters more than part stability. A robot can learn to handle variation in the parts themselves. But it cannot easily handle variation in the environment. Temperature swings, shadows from moving equipment, vibration from adjacent machinery—these break deployed systems faster than part variation does.
The job that survives is one where you have removed uncertainty before it reaches the robot. This is not limiting the robot. This is understanding what the robot can actually do.
Consistency is cheaper than flexibility. Building a feeder that orients parts costs less than building a robot vision system that can handle random orientation. Building a workbench with fixed lighting costs less than building a vision system that adapts to changing light.
The working robot is not the most advanced robot. It is the robot in a job designed so that it does not have to be.
Measure variability before deployment. If you cannot describe the range of conditions the robot will see, you are not ready to deploy. If you can describe it, you can usually reduce it.
What breaks deployed robots: the real failure modes
Drifting baselines kill robots faster than sudden failures. A robot works fine for two weeks, then starts missing picks. The parts supplier changed their packaging. The boxes arrive at a slightly different height. The robot's gripper was tuned for the old height. No one notices until throughput drops. This is not a hardware failure. It is invisible job drift.
Humans adjust the job around the robot, not the reverse. When a robot slows down, the line does not stop. Workers place parts closer to the gripper. They rotate items to make them easier to grab. They work around the machine. The robot keeps running, but now it is not doing the job it was trained to do. When the workaround breaks, the robot fails and no one knows why.
Lighting changes are invisible to humans and catastrophic to robots. A new LED panel goes up across the room. Shadows shift. The robot's vision system was trained under the old lighting. Suddenly it cannot find parts. The robot looks broken. The lighting change was invisible.
Seasonal variation accumulates. In winter, the warehouse is colder. Plastics are stiffer. Grippers slip. The robot was trained in summer. In December it starts failing. By January it is off the line. In March it works again. No one connects this to temperature.
Part substitution is the most common undeclared change. The supplier runs out of part A. Engineering approves part B as equivalent. Part B has a slightly different surface finish. The gripper slips. The vision system sees it differently. The robot fails. Procurement never tells manufacturing that the part changed.
Vibration from new equipment nearby can break vision-based systems. A new press starts running on the adjacent line. The vibration is imperceptible to humans. The camera on the robot jiggles. Image quality degrades. The detection system starts missing parts. The robot looks unreliable. The vibration was never measured.
Wear is not failure—it is predictable drift. A gripper finger wears down. Gripping force stays the same, but contact area shrinks. Slippage increases. The robot was trained with new fingers. After six months of running, it starts dropping parts. This is not a hardware fault. The job changed.
The working robot has monitoring for these invisible failures. It logs what it sees. It tracks cycle times. It records when it cannot find parts. This data tells you when the job is drifting before the robot stops working.
Robots fail silently more often than visibly. A visible failure is a crash or a stopped motor. A silent failure is running slower, or picking the wrong part, or doing 90% of the task and leaving a mess for the next step. Silent failures are harder to detect and more expensive to find.
The job that survives is one where you monitor what changes. Not just the robot. The job itself.
Designing work so the robot stays stable
Constrain the input, not the robot. Do not ask the robot to handle anything. Ask yourself: what is the smallest range of variation I can guarantee? Make that range the robot's target. The robot will work reliably within that range and nowhere outside it.
Use physical fixtures to lock down what the robot perceives. A parts nest that positions items identically every time is worth more than a smarter robot. A workbench with fixed mounting points is worth more than a robot that can adapt to moving surfaces. The robot works best when the world is fixed.
Separate sensing problems from handling problems. If the robot struggles to find a part, that is a sensing problem. Solve it by making parts easier to see—better lighting, contrasting background, fixed position—not by making the robot smarter. If the robot struggles to grip a part, that is a handling problem. Solve it by changing the part presentation or the gripper, not the robot's control system.
Build feedback loops that detect drift. The robot should log every action and its outcome. Did the gripper close fully? Did the vision system find the part in the expected location? Did the part move to the expected place? When these logs show drift, you can correct it before failure.
Plan for part substitution explicitly. When a part changes, the robot needs retuning. Build a process where part changes trigger a revalidation step. Do not let parts change invisibly. The cost of finding a part change early is much lower than the cost of a robot failing on the line.
Design the job to be reversible. The best job design is one where, if the robot fails, a human can finish the task quickly. If the robot gets stuck and a human needs 20 minutes to undo what it started, the job is not stable enough. If the robot fails and the human can take over in 30 seconds, the job is survivable.
Test the job under the actual conditions it will face. Not under ideal conditions. Not under the conditions the demo used. Under the real temperature range, the real lighting variation, the real vibration, the real part variation. Run it for at least two weeks before declaring success.
Document what the robot assumes about the job. Write down the lighting spec, the part orientation tolerance, the surface finish range, the vibration limit, the temperature range. When something changes, check this list first. This document is your early warning system.
Build redundancy into critical sensing. If the robot depends on one camera to find parts, a dust particle on the lens breaks it. If it has two cameras with independent lighting, one lens can get dirty and the robot still works. Redundancy is expensive but cheaper than downtime.
Keep the job simple enough that you can explain it to someone in five minutes. If the job design is too complex to explain, it is too fragile to maintain. A stable job is one the team understands completely.
Measuring stability before you declare a robot deployed
Run time is not the same as stable operation. A robot that runs for three days is not proven. A robot that runs for three weeks under varying conditions has shown something. A robot that runs for three months through a full seasonal cycle is stable. Set your proof threshold accordingly.
Count silent failures, not just visible ones. Every time the robot misses a part, drops an item, or delivers something to the wrong place—count it. These silent failures are how robots degrade. If silent failures are increasing over time, the job is drifting.
Measure variation in the inputs over time. Log the arrival time of each part. Log its orientation. Log its surface properties if the robot's vision system reads them. After two weeks, you will see what variation actually occurs. This is different from what you thought would occur.
Track cycle time as a stability indicator. A robot that runs the same task should maintain the same cycle time. If cycle time creeps up, something is wrong. The robot is being more careful because it is less certain. This is an early warning sign.
Do not trust a short successful run. Three days of success proves the robot can work under ideal conditions. It does not prove the job is stable. A lot of robotics projects fail in week three, after the initial excitement has faded and small variations have accumulated.
Test with the actual people who will maintain it. Your integration team can work around robot quirks. The production team cannot. If the production team cannot keep the robot running for a week, it is not deployed yet.
Declare stability when variation is bounded and predictable. Not when the robot is running. Not when it is running well. When you can predict what will go wrong and when, and you have a plan to handle it, the job is stable.
Build a decision point at week two. At day 14, do you have enough data to commit to deployment? If not, you need more test time. If yes, you can move forward. If you are unsure, the robot is not ready.
Keep a log of every change made to the robot or job after deployment. New gripper pads. Recalibrated camera. Adjusted lighting. Moved the workbench. Every change is data. Over months, this log tells you what the stable configuration actually is.
The moment you can stop thinking about the robot and it keeps working, you have achieved stability. Until then, you have a pilot project, not a deployed system.
When to redesign the job instead of upgrading the robot
If the robot is struggling with variation, the answer is usually not a better robot. It is a simpler job. Adding sensors and computing power makes the robot more expensive and harder to maintain. Removing sources of variation makes the job cheaper and more reliable.
The point where you should redesign the job is when the robot is working at the edge of its capability. When it is running slowly to be careful. When it is failing silently. When you are constantly tuning it. These are signs that the job has too much variation for this robot. Redesign the job, do not upgrade the robot.
Job redesign often costs less than robot capability. A better gripper is expensive. A feeder that presents parts more consistently is cheap. A better camera is expensive. Better lighting is cheap. A more powerful control system is expensive. Removing the need for that capability is cheap.
The robot that works is often the less capable robot in a better job. A simple gripper in a stable job beats a complex gripper in a chaotic job. A fixed camera in controlled lighting beats a mobile camera that adapts to shadows. Simplicity is stability.
Redesigning the job is also redesigning the robot's workload. The robot does not care what it does. But it works best when what it does is simple and repetitive. If you can make the task simpler, the robot will be more reliable.
The jobs that robots do well are jobs that have already been simplified by humans. Assembly line work. Bin picking from organized bins, not from chaotic piles. Welding in fixed positions. Palletizing where the pallet location does not change. These jobs worked well for humans because they were already simplified. Robots inherited those simplified jobs.
The jobs that robots struggle with are jobs that humans do well because they adapt constantly. Sorting mixed recycling. Handling soft goods that deform. Working in spaces where the layout changes. Robots struggle here because these jobs have not been simplified. Humans can improvise. Robots cannot.
Before you add robot capability, ask: can I simplify the job instead? Can I pre-sort the parts? Can I use a fixture? Can I change the lighting? Can I modify the part to make it easier to handle? Usually, the answer is yes, and it is cheaper than robot capability.
The decision to redesign the job is a decision to live with constraints. You cannot handle mixed parts. You cannot work in variable lighting. You cannot handle parts that vary in size. You accept these constraints in exchange for a robot that works reliably. Most deployed robots work because their jobs have accepted these constraints.
When the job constraints are unacceptable, that is when you need a different robot or a different approach. But first, make sure you have actually tried redesigning the job. Most teams do not try hard enough.
Frequently asked questions
How do I know if my robot job has too much variation?
The robot will show it through silent failures: missed picks, dropped parts, slower cycle times, or correct actions in the wrong sequence. If you are constantly tuning the robot or it works for a few days then degrades, the job has too much variation. The key is that the robot starts to behave inconsistently even though the robot itself has not changed. That inconsistency is the job, not the machine.
What is the difference between a robot failing and a job drifting?
A robot failure is sudden: a motor stops, a connection breaks, a component breaks. A job drift is gradual: the parts change slightly, lighting shifts, vibration increases, or a supplier changes their process. With robot failure, the robot is obviously broken. With job drift, the robot keeps working but does the job worse. Drift is harder to detect because it happens slowly enough that people adjust around it. By the time you notice, the robot has been failing silently for weeks.
Is designing the job to be robot-compatible the same as limiting what the robot can do?
Yes, and that is correct. A deployed robot is not a general-purpose machine. It is a specialized tool designed to do one task under specific conditions. The job design sets those conditions. A robot that can only handle parts in a narrow orientation range is not limited—it is focused. That focus is what makes it reliable. Trying to make the robot handle anything usually makes it handle nothing well.
When should I test a robot before saying it is deployed?
Run it for at least two weeks under real conditions. Measure silent failures every day. If silent failures are zero or stable, and cycle time is stable, and the team can maintain it without constant intervention, you can move to deployment. If silent failures are increasing or cycle time is creeping up, the job is still drifting. Do not declare success until you have seen a full production cycle and the robot has performed consistently through it.
More in Robots and jobs and Cost and selection.
