Robotic automation tailored to your business with ROS 2 and AI

In which tasks can artificial intelligence and robotics be handled together?

In one embodiment, the camera can determine the class or location of the part; The part ID and decision result can be transferred to task management via ROS 2. The robot controller or PLC checks the validity of this information and executes the defined workflow. The directing of the piece to the right place as well as the delivery of the message are verified in the physical pilot. In cases where the image or sensor result remains ambiguous, the behavior of operator review and local control is also defined.

Not every task requires a learning model. If fixed rules or existing measurement method meet the need, we consider it as an initial solution. If artificial intelligence will be used, it is stated for which product types and working conditions it will be accepted. Examples of incorrect acceptance, incorrect rejection and failure to produce results are monitored separately; A single success rate does not replace all the expectations of the business.

• Interpreting sensor data in manufacturing and robotic cells
• Matching work order and part ID with model decision
• Operator review flow for uncertain result

Data and task flow in robot automation systems with ROS 2

ROS 2 is a development framework that helps robotic software components exchange data and coordinate tasks. Sensor acquisition, model inference and task management can be organised as separate nodes. Continuous data is published through topics, short requests can use services, and tasks requiring progress and result tracking can use actions. Timestamps, device identity and error status define which operation each data item is valid for.

Depending on the need, Linux based industrial computer, single board computer and supported microcontrollers can be used together. micro-ROS is an option to connect suitable embedded platforms to the ROS 2 system with client and agent architecture. Task sharing between the central computer and distributed devices; It is designed with expectations of connection loss, reboots, and maintenance. Using ROS 2 does not mean that every board or robot is directly compatible; driver and manufacturer interfaces are examined.

• ROS 2 nodes and defined data interfaces
• Centralized or distributed software deployment
• Dedicated sensor board, embedded device and server connections

ROS 2 and industrial AI architecture guide →

How to determine whether to use CPU or GPU?

Model training and producing results from the trained model, that is, inference, are not the same workload. The model trained on a server can run on CPU in the field. In a more computationally intensive model, GPU can be evaluated; However, in case of small model, low data rate or limited energy budget, CPU may be a suitable option. We do not make the choice based on the name of the model or the advertising value of the equipment.

Candidate models are tested with actual data on the target device. We assess total sensor-to-result latency, latency variation, memory use, temperature and power consumption during extended operation. With a GPU, data-transfer overhead and unsupported operations remaining on the CPU can reduce the benefit. Model compression or changes in numerical precision require renewed validation of result quality. Suitable hardware meets the accepted accuracy and operating conditions.

• Planning training and field inference environments separately
• Comparative measurements using actual data and the target device
• Combined evaluation of performance, thermal behavior and maintenance cost

How to manage learning in closed-loop model development?

New or faulty examples encountered in the business can provide controlled feedback to the model development process. The steps of data recording, authorized review, label correction, new training and independent verification are defined. The dataset, model, preprocessing, and decision thresholds are versioned. It is also tested with previous acceptance samples to see whether the new version creates regressions in other products while correcting old bugs.

This cycle does not allow the deployed model to change unsupervised by treating its own decisions as correct. After authorised approval, the new model is tested in a limited pilot and deployed if accepted. A rollback path is retained. Changes in data distribution, uncertain results and cases referred for human review can be monitored. If operational data must remain on-site, collection, training and deployment infrastructure are planned accordingly.

• Internal data and revised labels
• Traceable versions of data, models and settings
• Human-approved update and rollback to previous version

How are boundaries defined with the existing PLC and machine control system?

We review the PLC or robot controller's existing tasks, accessible interfaces and manufacturer restrictions. Conditions for accepting a proposal or task request from ROS 2 are defined. Behaviour for stale results, duplicate commands, disconnections and timeouts is documented explicitly. Critical machine cycles and safety functions remain within the control and safety architecture they require.

In DDS based communication, QoS settings are selected according to the data flow; Not all messages are given a single setting. ROS_DOMAIN_ID serves to separate logical communication groups; It is not a substitute for access security. Network segmentation, authorization, appropriate ROS 2 security configuration and remote access policy are also planned. Adding artificial intelligence or ROS 2 does not automatically give the system a security certificate.

• Division of responsibilities between the PLC, robot controller and AI layer
• Command validity, timeout and error scenarios
• Network access and data communications security configuration

Custom electronics and software integration into existing control system →

How is deployment in an operating facility phased?

We first map existing equipment, data sources and production flow. Initial data supports offline experiments; where appropriate, simulation or a digital twin helps examine defined scenarios. These models are not assumed to represent all actual site conditions. During the first live stage, system outputs can be compared with the existing process without issuing commands. This shadow mode allows incorrect suggestions to be evaluated before they affect operations.

The pilot station's scope is agreed with the production plan. Testing covers normal operation, sensor loss, software restarts, network outages and incorrect model versions. Measurements and samples for site acceptance are specified in advance. Controlled commissioning follows clear authorisation, monitoring and rollback steps; expansion decisions rely on pilot records.

• Inventory and offline data evaluation
• Shadow operation, limited pilot and site acceptance
• Commissioning, monitoring and rollback plan

What technical deliverables are delivered at the end of development?

Application source codes, ROS 2 packages, interface definitions, configurations and technical documents of the project are included in the scope of delivery. If the model is developed, model files, version information, training and operating steps, and verification records are organized. Storage and transfer conditions of customer data are specified; Licenses for open source or commercial third-party components are disclosed separately.

Where a project includes custom electronics and mechanical development, the PCB design source files, CAD files and relevant production documents are also delivered at the end. Information needed for reinstallation, device replacement and updates is prepared. Rapid PCB fabrication and assembly support are offered within customer projects we develop. To request a quotation, share your existing devices, the task to solve, available data and expected project deliverables.

• Source code, model versions and configurations
• In-scope PCB/CAD source files and technical documentation
• Delivery records for installation, verification and maintenance