Perceive. Decide.
Act reliably.

A robot does not create economic value simply because it moves independently. A useful starting point is a recurring problem: employees sort changing parts, repeat the same visual inspection or move materials between two process steps. First define the required outcome and the issue that currently affects time, quality or ergonomics. Only then decide which technical solution fits.

Conventional automation works well when parts, positions and routines are well defined. A fixture can align parts; a simple sensor can establish a state unambiguously. AI becomes interesting when the relevant differences cannot reliably be described with a few fixed rules. Image analysis might distinguish part variants or estimate their pose. Whether this additional flexibility justifies its cost must be demonstrated in the real process.

For a fictional example, consider a cell that picks known part variants from a container, places them at an inspection position and assigns them to a destination container. Parts may lie in different positions within defined limits. Unknown variants, inadequate image quality and objects that cannot be gripped reliably are referred for assessment. The objective is a stable material flow with traceable inspection results, rather than the ability to grasp arbitrary objects.

Potential benefits take several forms: less repetitive handling, less manual identification of variants, reproducible documentation and better tracing of failures to their causes. Initially, these are hypotheses. Project planning must establish how to measure them and what should improve downstream as a result. A faster individual movement adds little value if the cell is constantly waiting for material or if quality approval remains a bottleneck afterwards.

A robotics application combines several decisions with different requirements. Perception processes sensor information and provides, for example, an object class, a pose and an estimate of uncertainty. Planning selects a permitted next step and calculates a suitable movement. Control implements approved instructions on the robotic system. A higher-level workflow controller records which order is being processed and what has already happened.

Separating these responsibilities makes failures distinguishable. A camera identifying the wrong part is a different problem from a correctly identified object that the gripper cannot physically hold. A geometrically feasible path may still be unsuitable because it would damage the workpiece or because the next process step is not ready. Each stage therefore needs clear inputs, verifiable outputs and a defined response to inadequate information.

Tools such as MoveIt can support motion planning and collision and constraint checks within a modelled workspace. Their results depend on that model and its currency. A computationally collision-free path does not independently establish machinery safety. The required protective functions and the assessment of the complete application are engineered separately.

In the example, the cell first recognises a known variant and checks whether the pose information is usable. Only then does it prepare a grasp attempt. After the movement, appropriate feedback confirms the actual state. If the grasp failed, the order must not be reported as complete. This feedback loop distinguishes a dependable workflow from a sequence of optimistic assumptions.

A training dataset should reflect the eventual task, not just well-lit sample parts. Relevant factors include variants, surface materials, contamination, packaging remnants, lighting and occlusion. Images without a usable object also belong in the dataset. If only successful situations are collected, the team learns too little about cases in which the installation must stop or request assistance.

Data needs a domain meaning that is actively maintained. What counts as a defect? Which pose deviation is acceptable? Which product version does a marking identify? Different interpretations among annotators can train a model towards conflicting objectives. A small, reviewed collection with clear rules may be more useful for an initial experiment than a large volume of ambiguously labelled images. Recordings, labels and rules are versioned together.

Training, tuning and final evaluation use separate datasets. Recordings of the same scene should not inadvertently appear on both sides. Evaluation can deliberately include different batches, production periods or permitted variants. This helps distinguish a useful learned discrimination from a model that mainly recognises peculiarities of the training setup.

Simulation helps investigate layouts and workflows before making a physical change. Synthetic data can supply additional image variations. Domain randomization varies factors such as light, material appearance or object pose; NVIDIA Isaac Sim and Replicator are among the tools that provide such capabilities. Differences between simulation and the real installation still need to be measured. A successful simulated grasp does not replace a trial with the actual material and gripper.

Feedback from operations is organised as a controlled learning process: capture unusual situations, review them with domain experts, extend the data, test a new model separately and then approve it. Autonomous learning directly in production would be a distinct system change with its own requirements. For many initial deployments, a frozen model with a traceable test record is the more manageable choice.

A hybrid architecture assigns tasks according to timing, availability and protection requirements. Image analysis and decisions close to the machinery can run locally at the cell. A central environment can manage data, develop models and combine analyses across sites. Approved cloud services can provide additional capacity. This allocation is an operational decision with reasons behind it, rather than an automatic ranking of newer and older technology.

Time-critical control and required protective functions must not depend without assessment on response times from a general-purpose language model or an external connection. Each interface needs a definition of how long a result remains valid and what happens on failure. Losing cloud access might delay an analysis while an approved local task continues. The specific system design determines which continued operation is permissible.

Agents can help above this execution layer: combine order information, retrieve approved work instructions, prepare a workflow proposal or assemble logs for investigating a fault. A knowledge graph can supply relationships between product version, recipe, tool and approval. This gives the agent better context. It does not automatically grant permission to control machinery or guarantee that the agent’s conclusion is correct.

A suitable runtime limits the tools an agent may use. Reading, proposing, changing parameters and starting a task are different permissions. Change requests are checked against approved ranges and the installation’s state; risk-relevant steps receive the designated human or technical approval. A free-form sentence is not translated directly into motor commands. Operations require traceable order identifiers, states and decisions.

ROS 2 is one possible component for communication between robotics modules; additional planning components may complement it. Choosing a framework does not, however, resolve real-time behaviour, safety or operational requirements. An architecture should make clear which component provides each commitment and how that commitment is verified.

Integration stands between a model experiment and a production installation. Good object recognition helps little if order data identifies the wrong variant or if the destination container has not been assigned. Product identifiers, recipe versions, material status and quality rules need an unambiguous meaning across the participating applications. It is worth establishing what a message means before selecting its technical transmission format.

An ERP system may provide orders and master data, an MES may coordinate production, and a quality application may manage inspection results. The specific allocation depends on the business. What matters is who creates an order, who accepts it and which event confirms completion. A delivered network request does not prove that a workpiece has been processed.

Interruptions belong in the normal design. After a restart, the system must establish whether a part is still in the gripper, has already been placed or has not yet been processed. Repeated messages must not silently trigger duplicate processing. The workflow therefore needs stable order identifiers, unambiguous state transitions and a restart strategy that accounts for the physical state. Where that state is uncertain, it is checked rather than guessed.

The mechanical environment is also an interface: gripper changes, fixtures, cables, light, cleaning, material supply and maintenance access all affect success. A change in packaging or surface finish may impair perception even when the part number stays the same. Production, maintenance, quality and IT should therefore work from a shared view of planned changes.

A clear operator interface is part of the solution. It shows the current order, the observed state, the reason for an interruption and the intended next step. A message such as “Variant could not be reliably identified — remove part for inspection” supports the work better than an internal model identifier. The interface must not offer an operation that is impermissible in the installation’s current state.

A robotics application is assessed with its intended use, operating modes and foreseeable misuse in mind. Relevant elements include the tool, workpiece, material feed, workspace and nearby people, as well as the robot arm. A system marketed as collaborative is not automatically harmless in every application. Tools and moving parts in particular can introduce risks that are not apparent from a view of the isolated product.

Protective measures follow the risk assessment of the specific application. They include appropriate engineering, verified protective functions and understandable operating instructions. A model’s confidence score is not a safety demonstration. An “approve” button is no substitute for a technical protective measure where the task requires one. An emergency stop likewise does not replace a considered protection concept.

Machinery law, occupational safety and any additional AI requirements are assessed together. In the EU context, the applicable machinery legislation and its transitional provisions must be considered; Machinery Regulation (EU) 2023/1230 replaces the Machinery Directive under the prescribed transition. Under the AI Act, assessment depends in part on intended purpose and the AI system’s role in the product. AI use alone does not place every vision application in the same category.

Roles and evidence are assigned early in the project: who is responsible for the complete application, who supplies which documentation, and who approves subsequent changes? Markings on individual components do not automatically carry over to the integrated installation. The necessary conformity assessment and operational duties remain distinct responsibilities for the relevant parties.

Cameras and logs may capture personal or confidential information. Necessary data, access rights, retention and permitted processing locations should therefore be defined during design. A camera’s field of view can often be limited to its task. Protected remote access, controlled software changes and a clear separation between operational and development environments also belong in the overall concept.

Meaningful evaluation begins with the eventual operating scope: which variants, materials, positions and environmental conditions are permitted? Deliberately selected cases outside those boundaries are added. The system does not need to process every possible object. It must, however, make clear when a task cannot reliably continue and invoke the defined response.

Perception errors are considered separately. Missing a defect has different consequences from unnecessarily referring a good part for further inspection. For handling, relevant outcomes include successful pickup, undamaged placement and confirmation of the destination. At process level, waiting time, repetitions, operator interventions and the quality of feedback also matter. A single average often hides the most important weaknesses.

A test plan combines known normal cases, difficult permitted cases and deliberately introduced disruptions. These may include an obstructed view, missing order information or an unavailable higher-level service. Such trials take place within an appropriate testing and protection concept. Successful behaviour is often an orderly interruption and a clear handover, rather than continuing at any cost.

Acceptance criteria should be established before optimisation begins. Otherwise, the project may end up measuring mainly what the solution already does well. Criteria can be defined for variants or task groups so that rare but important cases do not disappear in an overall average. The duration and conditions of a trial must also fit the eventual load; a short demonstration answers different questions from extended operation with changing material supply.

Observation remains necessary after approval. Dirty optics, changed materials, wear and new variants can alter performance. Monitoring should support actionable responses: check cleaning, investigate data quality, block a variant or return to an approved configuration. New models and recipes are evaluated again against the affected criteria before adoption.

An economic assessment needs a credible baseline. This includes actual processed volumes, productive time, scrap, rework, changeovers and the staff effort required for the workflow. Existing variation should remain visible. Otherwise, a proposed automated operation is being compared with an unrealistically uniform manual process.

Costs include integration, the protection concept, commissioning, data preparation, training, maintenance and later changes, as well as the installation itself. Ongoing expenditure for software, computing, spare parts and expert support also belongs in the assessment. An existing robot may make an initial project easier; it does not automatically eliminate these other items. Conversely, a small improvement to material feeding can create more value than a more elaborate model.

Freed working time initially represents capacity. It becomes a financial effect only when the business can use that capacity productively or avoid an actual cost. Higher throughput creates additional value only when demand and downstream capacity exist. Ergonomics, quality and delivery reliability may also be important objectives; their contribution should be evaluated with reasons rather than converted into apparently precise savings without evidence.

The interactive calculation makes assumptions visible. It compares staff minutes before and after automation, including review, and accounts for additional recurring operating costs. The valued time difference initially describes a capacity effect, not guaranteed cash savings. Its preset values are freely chosen scenario assumptions. For an investment decision, measurements and quotations replace them. The simple payback calculation is also extended to account for financing, ramp-up losses and tax.

A useful decision document includes at least a cautious, an expected and a favourable case. One particularly revealing question is which assumption could reverse the result: too many interventions, low utilisation, frequent variant changes or greater support effort. The pilot deliberately investigates that critical assumption. The calculation then supports a decision rather than merely justifying it afterwards.

A suitable starting point is a task that matters to the business and is sufficiently bounded. An initial workshop describes inputs, outcome, variants, exceptions, protection requirements and the current workflow. With the responsible teams, it establishes which uncertainty the pilot should resolve. That might be whether a surface can be recognised, whether a family of variants can be handled reliably or whether the cell can join the existing order flow.

Technical trials test the critical assumptions first. A bounded cell or suitable test setup then follows, with real interfaces and traceable states. Each phase needs a decision: continue, change the operating scope or choose a simpler approach. A negative result can be valuable if it prevents an unsuitable investment early.

Before operational handover, the project defines accountability, training, support, restart procedures and change control. Operators need understandable instructions for everyday work; maintenance and IT need access to information relevant to their responsibilities. An owner for models and data is as useful as an owner for the mechanics. These roles must work together when a new variant is introduced.

Scalevity brings together process understanding, AI development and software integration. This includes assessing suitable applications, designing data and system architecture, prototyping perception and agent functions, and connecting them to existing applications. Mechanics, installation design and safety engineering are coordinated with the necessary specialist disciplines and partners. The scope of services is defined by the task and the specialist disciplines it requires.

The objective is a traceable route from a concrete task to an operable system. Robotics and AI create value where flexible perception and decisions are connected to dependable workflows. The best next step is therefore usually a clear investigation brief: which process should improve, under what conditions, and which results will guide the next decision?