The robot already works. What it lacks is experience.
Factories have millions of installed robots. A proposed learning layer could turn logs, cameras and operator corrections into tested improvements.
Factories will not replace what they have installed. The opportunity is a layer that teaches it.
Another humanoid robot makes the news. Meanwhile, factories keep running arms they installed years ago.
The International Federation of Robotics reported on 24 September 2026 that about 5 million industrial robots now operate in factories worldwide. The stock grew 9% in 2025, and more than 600,000 new units were installed in that year alone. Few factories will scrap that fleet because a newer robot has legs. A cell that works is a cell that stays. My own planning judgment is to think in terms of 10-15 years of use, not a new robot every launch season.
I wrote in May that the robot is not the hard part, the factory is. This is the next thought: if the factory keeps its robots, what can we add to them?
My answer is experience.
What does an old robot actually know?
More than you would think. A robot that has picked parts in one cell for years has faced bad lighting, parts arriving the wrong way round and dusty shifts.
The problem is that much of this never leaves the cell. The program knows the motions. A few operators know the exceptions. The rest is scattered: a phone video from commissioning, a shop-floor camera rarely reviewed, an alarm log nobody reads twice.
So the robot works, and it does not learn. A new task can mean engineer time, reprogramming and a risk of breaking what already runs.
Where does the experience already live?
Before I generate anything, I want to look at what exists. On a typical floor there are more sources than people expect:
- Operator phones: videos of a new operation or a manual correction.
- Cameras that already watch the line, or the inside of a machine.
- Machine-vision cameras used for inspection, with their hard cases already filtered by someone.
- Telemetry: PLC and MES signals, alarms, retries, cycle results, downtime.
- Humans showing the operation once, from the side or from their own point of view.
What we want from them is specific. Failure episodes. The moment an operator corrected the situation. Rare events that are hard to film on purpose. And free labels: an alarm that fires at the same moment as a failed pick tells you which frames to look at.
Harvest first, generate second.
What does the learning layer do?
I think of it as one proposed loop on top of the robot, not instead of it:
- Observe the real work: cameras, robot state, commands, results.
- Harvest the experience that already exists around the machine.
- Find the gap: why did it fail, and what kind of example was missing?
- Create the missing experience: more real examples, a human demonstration, a simulation, or generated data.
- Validate: compare old and new on real events the model has never seen.
- Deploy the improvement to the edge, signed, with a way back.
Synthetic data lives in step four, as one tool among several. I say this on purpose. Generating data is already a crowded market with serious vendors, and “we can render what is hard to film” is not a position anyone can defend. The useful question comes before: is the gap really missing data? Sometimes a better light, a stronger augmentation or fifty more real examples fix it, and then the right answer is not to generate anything.
A new version only goes live if it beats the old one on real held-out events. If it does not, it stays in the lab.
What is a skill passport?
It would be a task-by-task record of how a robot performs, what version it runs and where it still fails. This is the part I understood first, because I come from the humanities side and I like a good document.
In this design, every robot would get a record per task: success rate, cycle time, how often a human had to step in, how often it recovered alone, which model version runs, how many training examples were real and how many synthetic, known weaknesses, and which hardware it runs on.
It turns “the AI got better” into a number someone can sign. It also travels with the robot. Germany has a long tradition of trusting a stamped document, so a robot with a passport should feel at home here.
Can this be added without touching the safety controller?
That is the design condition, not an afterthought. The existing controller stays the authority. The layer sits beside it, reads state, adds cameras, and may change what the safety envelope already allows: the vision model, grasp selection, task sequence, wait states, retry logic, parameters.
It does not bypass the safety function, does not raise drive limits and is never the only safety mechanism. Anything that changes behaviour still goes through the safety assessment of the whole cell. ISO 10218-2:2025 covers robot applications and cells. These are principles for the proposed design; the assessment and approval path for a specific retrofit would still need to be established with the safety engineer.
Why would an embedded engineering company build this?
Because most of the work is not machine learning.
A brownfield cell rarely offers a clean software stack. It offers an older controller, a fieldbus, a camera that needs a driver and timing constraints that do not care about a clever prototype. The work sits in PROFINET, EtherCAT and OPC UA connectors, in low-latency capture and deterministic vision processing, in edge compute that runs a model next to the line, and in making the whole box secure: secure boot, signed model updates, a way back when an update goes wrong.
That last point deserves attention. For a box that receives AI updates, I would include secure updates and lifecycle security in the design from the start, and check whether the EU Cyber Resilience Act applies to the specific implementation. That is a project principle, not a determination of legal scope.
Embedded teams also know the pattern of adding a function to a working platform without redesigning it. Promwad’s public case study describes adding analog video output to a modern vision platform through a Linux driver, without a board redesign. A learning layer is the same pattern, one level up.
What would the first proof of concept look like?
Small on purpose: exceptions in a tray before the robot grips.
One part family. One fixed camera above the tray. Two or three rare but visible situations: a part in the wrong orientation, a part hidden under another, a double stack. The camera spots the situation, and the existing robot gets a bounded answer: accept, skip, stop, or call an operator. No free navigation, no humanoid, no neural network inside a safety function.
Then comes the part I care about most, an honest comparison:
- real data only,
- real data plus ordinary augmentation,
- plus rendered scenes,
- plus generated variants,
- plus simply collecting more real examples at the same cost.
The test is real events that were held back from training. If generated data does not beat stronger plain methods at the same false-alarm rate, the right move is to stop and say so. I would propose a target of 25% fewer missed exceptions relative to the baseline, at the same false-alarm rate. That is a proposed test target to agree with a design partner, not a result.
The business case is also simple arithmetic. Take a station with 1,000,000 cycles a year, 1% costly errors, EUR 50 per event, and 30% of them preventable by better vision. That is EUR 150,000 a year before costs. At 100,000 cycles the same assumptions give EUR 15,000, which may be less than the solution costs. These are illustration numbers, not data from any customer. The point: the station has to be chosen by its error cost, not by how nice the demo looks.
What can I honestly say today?
No model has been trained for this yet. The only thing that has learned so far is me.
What exists is a plan, a list of hypotheses and a clear way to prove or kill them. To start I need a design partner with an installed cell, an error log, access to real images, and an engineer who is allowed to approve a test. The reference data has to be obtained legally, with the rights to use it written down. Raw production data stays on the customer’s site. Only what the contract allows leaves it.
If the first cell shows that the cheaper fix is a lamp, that is also a useful result.
Which robot on your floor knows something that nobody ever wrote down?