The instinct on most automation projects is to start with the robot: which brand, how many axes, what payload. It feels like progress. It is usually the last thing that should be decided, and starting there is how good budgets turn into stalled cells. The robot is one of the least decisive choices in the whole project. What decides the outcome is the part, the task, the tooling that touches the part, and the integration around it.
Across projects, the failures cluster in the same few places. None of them are about the arm.
The five places projects die
- Robot-first thinking. Teams over-index on robot brand when part presentation and the end-effector decide everything. The gripper or tool is where the task physically happens, and it is frequently the hardest, most custom part of the cell.
- Underestimated variability. Every part is the same is rarely true, and the exceptions are what break the cell. A neatly fixtured part and a part dumped randomly in a bin are different projects, often several times apart in cost.
- Skipped economics. Plenty of tasks are technically feasible but never justified. Automating something a human does cheaply and well is the largest single source of automation disappointment.
- Repeatability and accuracy confused. Returning to the same taught point is not the same as hitting a commanded position in absolute space. Specifying one when you needed the other produces a wrong, expensive match.
- Late-discovered closed-loop needs. Vision or force feedback found halfway in, after the cell was scoped as a blind, repeatable path, blows the budget. Whether the task is open-loop or closed-loop has to be settled early.
The honest fix
The fix is not a better robot. It is a process that runs in one direction: characterize the part, then the task, then the requirements, gate feasibility honestly, design the cell, and choose the robot near the end. The most valuable thing that process can say is sometimes no. This part is hard to present and likely needs a custom end-effector and a real conversation with an integrator, not an off-the-shelf match. A system that always returns a confident answer is one you stop believing.
That is the method Robtn follows, and it is why a feasibility eject is not a dead end. It is the most useful answer there is: a clear signal of what stays manual, what needs a human, and where the real engineering work is.