Skip to content

Blog · Robot integration

Vision-guided robot program selection: let a recognition result pick the program.

Updated July 2026 · 8 min read · Adente Vision Engineering Team

Vision-guided robot program selection lets an inspection unit recognize the part variant and output a program-select code, so the robot loads the matching path. At a leading automotive OEM the unit tells a left headlight from a right one and reads bumper variants above 0.9 confidence, then signals the controller which program to run.

How does a recognition result choose the robot program?

Vision-guided robot program selection is a three-step pattern: the unit recognizes which variant is in front of it, outputs a program-select code, and the robot switches to the matching path. Instead of assuming every part on the line is the same, the cell reads the part first and adapts the motion, fixture and torque program to what actually arrived.

In industrial automation this pattern is common wherever one station handles more than one part. A robot controller stores several programs, one per variant, and waits for a selection signal before it runs. The open question is what produces that signal reliably at line speed. A hard-coded sequence assumes the build order never changes; a barcode or RFID tag works only if the part carries one. A recognition result closes the gap for unmarked parts by identifying the variant from its appearance.

Adente Vision is an edge-AI visual inspection unit built by ADENTE Advanced Engineering Technologies, part of the Aden Group, sold through automation system integrators, and turning a recognition result into a robot program-select signal is one of its core jobs. The recognition and the output happen on-device, so there is no separate PC or cloud call between seeing the part and steering the robot.

Why start with the headlight left-versus-right case?

At a leading automotive OEM, the unit distinguishes a left headlight from a right one and tells the robot which program to run. The two parts are near-mirror images, easy to confuse on a fast line, and expensive to get wrong downstream: a mismatched fixture, a torque sequence for the other side, or a good part rejected because the wrong program ran.

The unit captures the headlight as it indexes into frame, classifies which side it is, and emits a program-select signal to the controller. The robot then loads the matching program: the correct pick, the correct fixture, the correct torque routine for that specific side. Recognition and action sit in the same step, so the decision reaches the robot before it moves.

Because the model learns each variant from good examples rather than a hand-written rule, near-mirror parts that defeat a threshold-based check become a classification the model handles directly. That is the band appearance-level recognition is built for, and it is why a left-versus-right call is a natural first job for the pattern.

How does bumper variant recognition raise confidence above the threshold?

Bumper recognition works the same way, with per-part confidence above 0.9. Each bumper is classified as it arrives, and the confidence score is the number the cell acts on: above the operating threshold the robot proceeds with the matched program, and below it the part is routed to a safe default rather than guessed.

That confidence-first design matters because the cost of a confident wrong answer is high. A borderline part should stop and be checked, not be forced into a class to keep the line moving. Exposing the score lets your integrator set the operating point to the cell's real cost of a mismatch, tighter where a wrong program damages a part, looser where the recovery is cheap.

The safe default is the part of the design people forget. When recognition is ambiguous, the cell needs a defined fallback: hold the part, route it to a manual station, or run a neutral program that does no harm. Deciding that fallback up front is what keeps a rare low-confidence read from becoming a crash.

How does each recognition result map to a robot program?

One unit covers variant recognition and the fallback, and each result leaves as a signal the controller already understands.

Recognition resultWhat the unit outputsHow the robot uses it
Headlight left vs rightProgram-select code for the recognized sideLoads the pick, fixture and torque program for that side
Bumper variant, confidence above 0.9Program-select integer for the matched variantRuns the matched program path
Confidence below the thresholdSafe-default code, no forced classHolds the part or runs a neutral program
No part or wrong part presentFault or not-ready signalInterlocks the robot until the part is correct

Should you carry the selection over a fieldbus or bit-code it on I/O?

There are two ways to get the selection to the robot, and which one fits depends on how many variants you run. A selection integer carried over a fieldbus scales to many programs, while bit-coding across discrete outputs is the simplest path when a station handles only a few.

The unit has 4 outputs at 24V, which can bit-code a small set of variants directly: four outputs cover several program codes with room for a fault line, enough for a station that runs two or three parts. For a larger program set, a selection integer over the fieldbus your controller already speaks is cleaner than adding I/O. In industrial automation the usual pairing is PROFINET on Siemens controllers and EtherNet/IP on Rockwell controllers, and the unit carries the selection over whichever the PLC already speaks, so the recognition result and the reject action ride the same bus the line was built on.

Whichever carrier you pick, keep the fault and not-ready lines in the map. A recognition cell is only safe if the robot can tell the difference between a valid selection, an ambiguous read, and no signal at all.

What makes this a training task, not a re-engineering task?

Adding a third or fourth variant later is a capture-and-train task, not a re-engineering task. You capture about 20 good images of the new variant, the model learns it, and training completes under 48 hours, so a new part does not reopen the cell's mechanical design.

Because the model trains on good parts only, you do not have to collect a catalogue of every defect before you start, which is what keeps the data requirement small. The unit runs four modes, Anomaly, Defect, Counting and Quality, and combines classical computer vision for measurement with AI inference for judgement, so alongside picking the robot program it can also flag a surface defect or a missing clip on the same part. For when to use AI recognition versus a rule-based check, see the sibling post on rule-based versus AI machine vision, and for how a semantic protocol carries richer results, see the note on OPC UA for inspection. The full method behind few-shot recognition and anomaly detection is in the pillar guide, and the recognition and defect capabilities behind this pattern are on the Adente Vision applications page.

Frequently asked questions

Running a robot cell that handles more than one variant?

Send us sample parts or a short video of the line, and we show the recognition result and the program-select signal before quoting. See how Adente Vision drives a robot program from a recognition result on the edge.