Using AI to Configure Robot Cells, Not Run Them

August 25, 2026

Kristian Hulgård

Image Source: OnRobot

By Kristian Hulgård, General Manager, Americas, OnRobot, for Mouser

Published August 25, 2026

Artificial intelligence (AI) might be the most overused term on the plant floor right now, and much of what is labeled AI in automation is fairly limited. That makes precision more important. Consider a robot cell, a self-contained workstation in which a robot, its tooling, and its safety and control hardware perform a single task. Whether AI helps or hinders that cell depends on which part of the work it handles: the setup or the cycle.

The first is setup: laying out a task, adapting to a new product, and turning changing inputs into a workable plan. The second is the cycle: the repeated motion, timing, and interlocks that must execute consistently every time. The setup is typically where engineering hours and service calls accumulate, and teams must revisit it whenever a product changes.

The difference is checkability, or the ability to determine whether an automated or AI-generated output is correct. AI is useful for setup, where inputs vary and manufacturers can verify the generated plan before any part of the system moves. It becomes a liability on the cycle, where it directly controls repeatable machine motion, because a single anomalous decision can drop a load or crash the cell.

The principle is straightforward: Use AI to produce the setup, and keep it out of the cycle that runs repeatedly. Deployments that disappoint rarely fail because the AI was weak. They fail because the engineering scope was not fully defined before the system was deployed. A reliable structure assigns each step to the part of the system suited to it. AI generates the setup; deterministic engineering rules validate it; standard machine controls execute it; and human operators handle the cases that do not fit.

This article examines the practical role of AI in robot cells, identifying where AI can improve flexibility and where deterministic controls remain essential for safe, repeatable operation.

Prevent Deployment Failure by Controlling Scope

A large manufacturer approached OnRobot with a routine task to pick up a box and place it on a pallet. Palletizing is one of the most common automation tasks, and our tools handle it directly (Figure 1). We scoped the job together, agreed on the cell’s requirements, and began building.

Figure 1: The OnRobot MoveComponents palletizer’s compact design and small footprint fit easily into existing work cells. (Source: OnRobot)

Then the engineer who owned the project left the company. The replacement engineer added requirements: another conveyor, then several more, plus product flows not included in the original scope. No single change was unreasonable, but each one moved the cell further from the agreed specification, and no one revalidated the system against that specification as the changes accumulated.

By the time the divergence became clear, the system under construction no longer aligned with the manufacturer’s scope, and no one could make it work. The project fell apart. The software never failed. The specification failed, one reasonable-sounding request at a time. Many reports of “the AI did not work” describe the same pattern.

Define What AI Controls and What It Doesn’t

Consider the palletizing job again. Previously, introducing a new box size required significant engineering effort: lay out the stacking pattern by hand, confirm the stack will not topple or overhang the edge, program each placement, and test it. That could take hours, often requiring a service call.

With a tool such as OnRobot’s D:PLOY platform, an operator enters the workpiece attributes and pick position. The software automatically detects connected hardware, generates a collision-free path, and produces the application’s program logic, signal exchanges, and event handling without manual programming. For a palletizing job, the operator supplies the box and pallet parameters, and the software returns a stacking pattern and placement order. According to OnRobot, a palletizing application can run in as little as four hours, up to 90 percent faster than a conventional setup.^[1] That step is valuable, and exactly the kind of work—converting changing inputs into a workable plan—that should be assigned to software.

The plan does not go directly to the robot. First, the engineering rules check it against fixed constraints. Will the stack remain upright? Does it stay within the pallet footprint? Is every box reachable within the robot’s work envelope? Can the gripper pick it up? Can the cell meet the required cycle time? Any pattern that fails any of these checks never reaches the floor.

Only after a pattern passes does the robot execute it. The execution, including motion, conveyor timing, interlocks, and emergency stop (e-stop) circuits, remains within standard machine controls, and the same action repeats each cycle. When the software cannot find a pattern that passes—whether due to a damaged box, an unusual stock-keeping unit (SKU), or a condition the cell was not built for—it stops and requests an operator rather than forcing a bad stack.

That is the full model in a single job. The software proposes a setup, fixed rules accept or reject it, and standard controls run whatever passes. A person handles only the exceptions. The AI never touches the part of the process where a wrong move could cause damage.

The hardware must align with this approach. AI is most useful when parts move, vary, or arrive in inconsistent positions, and those parts are often the hardest to grasp. A flexible setup uses a gripper that tolerates dimensional variation, adjusts grip force, and feeds position and force back to the controller. A well-generated pattern is useless if the gripper cannot pick up the box.

Evaluate the Job for Robotics, Then for AI

Two separate decisions underlie every cell. The first is whether a robot belongs on the task. The second is whether AI should generate the setup.

For the first decision, we use a simple “three-Ds” test: Is the task dull, dirty, or dangerous? If it is any of those, consider using a robot. Palletizing usually qualifies as all three; it is repetitive, often done in dust or cold, and requires continually lifting boxes for a full shift.

The second decision applies only after the team has determined that using a robot is appropriate. The following questions help determine whether implementing AI is suitable.

Does the job actually vary? If every cycle is identical, leave it in standard controls. AI is justified only where inputs change (e.g., new products, parts in different positions, alarms with intermittent fault histories, operator requests that must be converted into machine actions).
Can you define success numerically? Deployment relies on quantifying success. For example, palletization success is concrete: The stack stays upright and within the footprint, keeps its center of gravity in bounds, and meets the required throughput and cycle time. In troubleshooting, success may be measured by the rate at which the first proposed fix resolves the fault.
Can you validate the output before the machine acts on it? You can review and reject a pallet pattern or setup recipe at no cost before anything moves. You cannot review a split-second motion decision before it executes, which is why that class of decision stays in deterministic controls rather than AI.
What happens when the output is wrong? Decide in advance: If the output is wrong, will you revert to a known-good recipe, stop and call a person, or escalate to engineering? If you have not planned for a bad output, the planning is not finished.

Different AI tools place the burden of data quality in different places. The type described here generates a setup that the rules then validate, and it logs its own operating data, so the customer does not have to maintain a large dataset. A second type of AI tool learns a task from repeated demonstrations and improves the more it is shown. With that type, the quality of training determines the quality of results.

Define the Cell Requirements Before Purchase

The most useful time in any deployment is spent specifying what the cell must do before any purchase.

Record the real engineering constraints, such as worst-case combined weight of part and gripper, reach, work envelope, part presentation, cycle time sustained over a full shift, machine signals, safety requirements, and likely future product changes. A vendor or integrator can usually tell you quickly whether their tool fits.

You can do this engineering yourself and hand the specification to an integrator, or you can buy a pre-engineered system. The latter route is where the cost savings come from.

One OnRobot customer sells a pre-engineered palletizing system that runs on D:PLOY. Because the system is pre-built and pre-validated for a specific job, the customer avoids months of design and testing. For projects that fit the system’s scope, deployments that once took several months now take about a week. In my experience, a packaged system can also cost a fraction of a custom cell, and the savings come from reusing engineering.

Measure Whether the Deployment Delivered Results

Demonstrations are great, but they do not guarantee success. What matters is whether the business has improved. Before installation, collect the data you already have, such as changeover duration, engineering hours per changeover, service calls, downtime, throughput, scrap rate, the number of products the line can handle, and operator training time. Set a payback target. Then track the same parameters once the cell is operational. Outcomes that justify the project may include changeover times reduced from hours to minutes, fewer service calls, or handling three additional products without adding staff.

When the numbers fall short, do not assume the AI failed. Perhaps a condition has changed. In my experience, the most common cause is ownership: The person who configured the cell is no longer with the company, and the remaining staff know only how to start it. No one maintains the cell or updates it when the work changes.

Automation is not a one-time installation. It needs an owner, who should be identified from the start.

Start with the Right Application and Ownership

In many cases, companies are installing robots in response to a documented and growing labor shortage. A 2018 Deloitte and Manufacturing Institute study projected that 2.4 million US manufacturing positions could go unfilled between 2018 and 2028, driven in part by more than 2.6 million baby boomer retirements over the decade.^[2] As the older workforce retires and fewer young workers enter these roles, the industry must produce more to remain competitive. Adding a robot to a palletizing line allows an operator who used to stack boxes by hand to run several cells simultaneously.

Contrary to what many people picture, much of US manufacturing does not come from large, automated factories. Instead, small manufacturing firms account for 98 percent of all manufacturing firms in the United States.^[3] These plants still rely on human workers because the processes are difficult, and they are exactly where a first robot on the palletizing line frees a person for work that requires judgment.

When first considering automation, companies should keep it simple: palletizing, computer numerical control (CNC) machine tending, or packaging. Do not assume that, because AI exists, you can automate an entire plant within a quarter. Visit an automation trade show to see these tools in action, or ask your local integrator or distributor to demonstrate a tool that fits your application.

Conclusion

Every AI automation decision is constrained by checkability. You can validate or reject a generated setup before the cell moves, but you cannot stop a runtime motion decision before it is executed. This is why AI is best applied to setup and exception handling, while the repeated cycle is best left to deterministic controls.

My own expectation is incremental, expanding only after each cell proves itself in production. The payoff appears only when you finish the engineering first: Packaged systems shorten deployment because the vendor reuses proven engineering. Two constraints remain unresolved. The “learned from demonstration” tool class depends on the quality of the training data the customer supplies, and every deployed cell needs a reliable owner as the work evolves.

For a technical decision-maker, the actions are concrete. Confirm that the job varies and that you can define success numerically. Require deterministic rules to validate every AI-generated setup before it runs. Keep the cycle in deterministic controls. Assign an owner on day one, and measure changeover hours, service calls, scrap, and throughput against a pre-installation baseline. Complete that engineering, and these tools will deliver what their vendors specify.