Using AI to Configure Robot Cells, Not Run Them
Key Highlights
- AI excels in setup tasks such as generating collision-free paths and adapting to changing inputs, reducing engineering hours and setup time.
- Deterministic controls are essential for executing repeatable motions and ensuring safety during cycle operations, preventing errors from anomalous AI decisions.
- Clear scope definition and validation of AI-generated plans are critical to prevent deployment failures caused by scope creep and unverified outputs.
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.
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.
>>Click to read the entire article at Mouser
