Muskeology
Frontier tech, minus the hype

Robotics

Buying robots: the questions that matter

For anyone evaluating an automation proposal, the specification sheet is the least useful document in the pack.

Anonymous male mechanic in uniform fixing detail of spacecraft while working at modern headquarter of industrial factory
Anonymous male mechanic in uniform fixing detail of spacecraft while working at modern headquarter of industrial factory · Photo via Pexels

Automation projects fail more often on integration and process than on the machine. The questions that predict success are mostly not about the robot.

What is the actual task

Specified precisely, in terms a machine could be evaluated against.

Not "pack boxes" but: which products, at what rate, arriving how, in what orientation, with what variation, into what container, at what accuracy, with what failure tolerance.

Most disappointing deployments trace back to a task specified loosely and discovered to be more variable than assumed.

What is the variation

The single strongest predictor of difficulty.

How many product variants? How often do they change? What is the tolerance on incoming parts? How consistently are they presented?

A system that handles ten known variants is a different engineering problem from one that handles arbitrary items, by roughly an order of magnitude in cost.

Reducing variation upstream — standardising packaging, fixturing parts, sorting before the cell — is frequently cheaper than building a robot that tolerates it.

What happens when it fails

Every automated cell stops. The question is what that costs and who resolves it.

What is the expected intervention rate? Who is available to intervene, on which shifts? What is the mean time to recovery? Does a stoppage block an entire line or only one station?

A system with a ninety-eight percent success rate that requires a technician for each failure may be worse than one at ninety-five percent that an operator clears in thirty seconds.

What is the true cost

The hardware price is the smallest component in most projects.

Add: end-of-arm tooling, fixtures, safety systems and assessment, controls integration, programming, site preparation, commissioning, training, spares, maintenance contracts, and the internal engineering time to specify and manage it.

Integration commonly exceeds hardware cost, sometimes by a large multiple.

Then add the cost of production disruption during installation and ramp-up, which is routinely omitted from business cases and routinely material.

What is the payback, honestly

Calculated against what actually changes.

If the system replaces two operators on one shift, the saving is two operators on one shift — not three shifts, unless it runs three shifts.

If throughput is limited by an upstream process, automating a downstream station saves labour and adds no output.

Quality improvements and injury reduction are real benefits and are harder to quantify. State them separately rather than folding optimistic numbers into the payback.

Who supports it in year three

The question that separates a successful installation from an expensive fixture.

Is there internal capability to modify the program when the product changes? Or does every change require a service call?

Are spares available and at what lead time? Is the integrator still in business? Is the controller platform still supported?

A great many idle robots in factories are there because the one person who understood the cell left.

Can it be reused

Products change. A cell built rigidly around one product becomes worthless when that product does.

Flexible tooling, standard interfaces and reprogrammable rather than hard-coded behaviour cost more initially and preserve the asset.

What does the workforce think

Not a soft consideration.

The operators know where the process actually varies, which failures are common, and which parts of the task are hardest — information that is rarely in the specification and always in their heads.

Projects that involve them early specify better and get better outcomes. Projects that do not encounter both worse specifications and, unsurprisingly, less cooperation.

And whether the change is presented as replacing people or as removing the worst parts of their work materially affects both.

The pilot question

Insist on one, on your own parts, in your own conditions, at your own rate.

Vendor demonstrations use prepared parts in controlled conditions. The gap between that and a Tuesday afternoon with a batch that came in slightly out of tolerance is where projects fail.

A pilot that runs for a week on real production, with real interruptions, measured for intervention rate rather than for peak throughput, tells you what you need to know.

If a vendor will not agree to that, the answer to the procurement question has arrived early.

Tobias Nkemelu
AI & Compute, Muskeology

Tobias builds and breaks machine learning systems for a living, which makes him a difficult audience for benchmark announcements.

More from Tobias →

Also by Tobias Nkemelu

Robotics

Autonomous mobile robots outside the warehouse

Hospitals, hotels, factories and pavements — where wheeled autonomy has spread, and the specific reasons each environment is harder than a warehouse.

Lena Brandt··3 min read

AI & Compute

Evaluating an AI product claim

A short checklist for reading announcements, which mostly consists of asking what was measured and against what.

Tobias Nkemelu··3 min read