Blog post

From Vibration to Repair: An Edge Agentic AI Conveyor with Edge Impulse, UNS, and Arduino VENTUNO Q

arduino
By Marc Pous
From Vibration to Repair: An Edge Agentic AI Conveyor with Edge Impulse, UNS, and Arduino VENTUNO Q

The new Arduino VENTUNO Q board just launched, bringing an impressive array of power and ports, along with the unique hybrid SBC/MCU architecture first introduced with the Arduino UNO Q a few months ago.

To explore the power of the VENTUNO Q, we built an industrial automation project adding anomaly detection, a Unified Namespace backbone, and on-device AI agents so the machine can detect potential issues, decide what to do, and coordinate the fix itself. This gives machine builders a practical path from "sensor to alarm" to an autonomous edge "vibration to repair" solution.

Introduction: Predicting Anomalies with Vibration

In 2026 machine builders, engineers who design and build industrial machinery, still ship industrial equipment that mostly reacts with fixed thresholds and alarms. When something goes wrong, a human has to notice, triage, open a work order, and re-plan production. That loop is slow, expensive, and hard to scale.

Today most of the industrial line relies on moving or rotating elements: filling lines, conveyors, pumps, compressors, and packaging lines all depend on machinery that deteriorates over time. As parts loosen and degrade, the symptoms appear first as subtle changes in vibration long before a failure actually stops production. And stopping production is a very expensive problem to have in a factory. 

That is why vibration sensors are among the most common sensors on a plant floor. They give you a measurable signal. The challenge is that a raw vibration reading is just a number. Someone still has to interpret it, decide whether it matters, and trigger the right response across maintenance and production teams. 

The opportunity is to close that gap at the edge, in the sensor itself. Imagine a vibration sensor that could detect anomalies automatically, reason about them locally, and plan a maintenance window before a machine ever fails.

Quick Primer: From Industry 3.0 to 5.0

(As this project is heavily focused on industrial uses, it's helpful to provide context to non-industry experts. Feel free to jump to "The Project" section if you know the terms Industry 3.0, 4.0, and 5.0.)

The concept of Industry 3.0 started from the 1970s and introduced programmable logic controllers (PLCs) and robotics through automated lines to the factory floor. Automation was the main goal with lines running unattended, repeating the same operations multiple times. But the automation was organized in silos. Later, SCADA systems were trying to interconnect all the different machines and systems in the factories, however each integration among PLCs, robots, systems and SCADA was tailor-made.

Industry 4.0 changed the conversation from automation to integration. Instead of polling data from machines one by one via complex integrations to the SCADA, ERP, MES or similar system, the plant floor began to publish its data to a common, event-driven backbone or database: the single source of truth. Today, most modern devices ship with OPC-UA or MQTT support, and legacy equipment can be bridged with modest effort; the integration is more simple than in previous eras. Any service can now publish and subscribe in real-time to any topic. Walker Reynolds coined the concept of the Unified Namespace (UNS), which is a real-time single source of truth based on MQTT for the whole corporation business, organized along the industrial standard ISA-95 model. From a vibration sensor reading to enterprise KPIs. (Learn more about UNS in the section below.)

Nowadays Industry 5.0 adds the element that integration alone could not deliver, which is action. Sensors, actuators, PLCs, and services do not only publish and subscribe data around through the UNS, they can run local AI models to reason and act on their own, depending on themselves and the context. The conveyor stops being a sensor that reports anomalous numbers running inference on a local ML model. An anomaly is not just logged, it is interpreted, triaged, and seen via the UNS and turned into a maintenance window that re-plans production before the machine ever fails.

That shift is exactly what we are building here with Edge Impulse, agentic AI, and the Arduino VENTUNO Q.

What is the Unified Namespace

In most of the factories, data still used to live in silos. SCADA, MES, WMS, dashboards, databases, and custom scripts each keep their own copy of the truth (or a subset). When a sensor reading changes, not every system sees it at the same time and adding a new system is complex.

The alternative is a shared, real-time picture of the business that every machine, service, and person can read and write without being wired directly one to another. That is what the UNS brings.

The UNS is a concept coined by Walker Reynolds. It is the semantic hierarchy that connects every layer of the manufacturing stack. From a vibration sensor all the way up to enterprise KPIs, work orders and invoices. A human, a machine or a service can subscribe to a part or the whole business and get notified when something changes.

The easiest way to explain the UNS is a picture of the file system of your factory. Every event, every reading, every decision has a place in a topical hierarchy organized by location and function. There is no central application that owns the data, or stores it, and no point-to-point spaghetti integration between systems. There is just the namespace, and everyone publishes and subscribes to it. As an example, if you want to store raw data in a database, a script will subscribe to those topics and store the data when they change in real-time. 

That makes the UNS the single source of truth for the current state of every sensor, actuator, or service, and it lets independent software systems cooperate without ever being wired directly to one another. The UNS concept uses MQTT to take advantage of the MQTT topics which are the transport layer that makes this possible.

To give the hierarchy a standard shape, the UNS model the MQTT topics following the industrial standard ISA-95. This is the plant-floor equipment model that most of the industry already agrees on: 

Enterprise
  Site
    Area
      Line
        Work Cell
          Equipment

The Project: Conveyor Vibration Fault Sensing

Note: This project it is for illustrative and educational purposes only

Traditionally, decision-making for industrial machinery relied on vibration data processed on a central server, or on workers visually inspecting the machines on the shop floor.

This project takes a different approach. It is an industrial reference design for machine builders. This is a prototype of a conveyor vibration sensor which detects its own faults, reasons about them with different local AI models, and coordinates its own repair when needed. All on a single board, at the edge, with no cloud required and using a UNS with a MQTT broker to manage coordination with the enterprise.

This project turns the new Arduino VENTUNO Q into a self-contained Industry 5.0 prototype. It shows all three on industrial-grade edge hardware (Qualcomm Dragonwing IQ8, Hexagon NPU, dual MPU + MCU design).

The board:

As a prototype, everything runs on one device. The goal is to give machine builders a reference edge AI architecture they can adapt to real conveyors, compressors, or other rotating equipment.

The Unified Namespace (UNS)

This is how the prototype described here is mapped onto the UNS. We are representing a packaging line based in our factory in Barcelona. The conveyor's vibration sensor in the corporation looks like this:

Enterprise → ACME
  Site → Barcelona
    Area → Packaging
      Line → Line_1
        Work Cell → Conveyor_1
          Equipment→ Vibration (Arduino VENTUNO Q)

Which turns into a set of MQTT topics:

Acme/Barcelona/Packaging/Line_1/Conveyor_1/vibration/raw
Acme/Barcelona/Packaging/Line_1/Conveyor_1/vibration/anomaly_score
Acme/Barcelona/Packaging/Line_1/Conveyor_1/vibration/verdict
Acme/Barcelona/Packaging/Line_1/Conveyor_1/maintenance/window
Acme/Barcelona/Packaging/Line_1/Conveyor_1/production/plan
Acme/Barcelona/Packaging/Line_1/Conveyor_1/kpi/oee
...

When the conveyor's vibration changes, the `raw vibration` is published but as well everything else that cares. The dashboard, the agents, the KPIs and other services subscribed see the anomaly at the same instant and proceed as expected.

The demo makes the whole thing self-contained, with the UNS MQTT broker running as an Arduino App Lab custom brick. The single board plays the role of the entire enterprise stack, which isn't how a real factory setup works. In an actual deployment, you'd point to your plant's existing MQTT broker, and the corporate and maintenance agents would run on other machines — but nothing else would change.

The AI Agents

The UNS is ideal for publishing and subscribing real-time state: vibration raw data, machine health, KPIs, and others. However it is not ideal for work. When one specialist needs another to do something specific (e.g. open a maintenance window, re-plan production, update a WMS) broadcasting that request on MQTT mixes tasks with telemetry and makes ownership unclear.

The alternative is to hard-wire agents together or put all logic in one monolithic service. That becomes a mess as soon as you add roles or scale beyond a single machine, as previously during the Industry 3.0 solutions.

With the goal of maintaining everything decentralized we keep two complementary channels:

In this project, A2A (using patterns aligned with Google’s A2A protocol and LangChain-style tooling) is how agents delegate concrete work. 

For example:

This separation keeps the architecture scalable. New agents can subscribe to the UNS for context and use A2A when they need another agent to act. For a deeper treatment of multi-agent industrial systems with A2A, see Kudzai Manditereza’s Agentic AI for Industrial Systems.

The Dashboard

Shop floors already rely on HMIs for operators and dashboards for IT, engineers and managers. Those views are essential, but they rarely show the full picture at once. They don’t show live sensor inference, the enterprise topic tree, agent decisions, and manufacturing KPIs.

This prototype creates a lightweight web dashboard that sits beside those existing tools. It does not replace the HMI or the MES. It makes the edge actions visible, so the teams can see what the system detects, what the agents decide, and how production metrics react.

The app serves a four-panel dashboard with 4 different panels:

Getting started

Hardware

No physical machine is required to run the demo.

Software

Arduino App Lab bricks:

The application 

Once the app is running in the Arduino VENTUNO Q, a simulator (or could be a real sensor) publishes vibration windows. There is an Edge Impulse model scoring and publishing as health/anomaly events with a verdict using Anomaly Detection model.

A local maintenance agent is subscribed to these events from the Unified Namespace, reasons over them with a local LLM, and decides whether to issue a repair or dismiss the event as a false alarm. If the anomaly is real, the maintenance agent creates a work order and calls a corporate agent via the Agent2Agent (A2A) protocol.

The corporate agent opens a maintenance window and transitions the machine state to maintenance. A planning agent sees the window and re-plans production accordingly, while a KPI service updates OEE, cost, and production rate in real-time. Once the maintenance job gets done, the machine returns to a healthy state and the loop repeats when an anomaly gets detected.

For demo purposes there is a “Trigger anomaly” button on the dashboard that forces the loop for live demos.

The AI model

The anomaly detector is an Edge Impulse model built from a Spectral Analysis DSP block feeding a K-means anomaly detection block, served on-device by the vibration_anomaly_detection Arduino App Lab brick, however it can run using any Edge Impulse SDK (C++, Python, and CLI).

Why K-means anomaly detection instead of a classifier? Because in the real world you rarely have neatly labeled examples of every way a machine can break. However you always have plenty of examples of it running well. So the model learns the healthy vibration patterns and then anything that is different than the patterns is detected as an anomaly. To train this model, no fault dataset is required.

The raw data of the vibration sensor, the anomaly score and the verdict are published to the UNS, and the moment an anomaly score higher than expected is published, the maintenance agent, which is subscribed to the UNS, wakes up.

Find here examples of the captured data to train the anomaly detection machine learning model.

This is healthy vibration stored in the Training Dataset to train the ML model
Unhealthy vibration stored in the Test Dataset

In the other hand, the 3 agents use the same local LLM brick with the Qwen3 4b model. They keep short memory and publish reasoning traces back into the UNS so the dashboard can show why a decision was made.

The dashboard

A web dashboard is published in the local ip address of the board in the port 5001 distributed in 4 panels:

  1. Vibration & inference
  2. Unified Namespace
  3. Agents thinking
  4. and the Manufacturing KPIs

How to run it

1. Clone the repo

Clone Github this repository or just download the .zip file with the code.

2. Train (or reuse) the anomaly model in Edge Impulse

3. Run on the VENTUNO Q

Now you can re-train the model if you bring the Edge Impulse project API key and click Record 10s. Then going to Edge Impulse Studio re-train the model with more data.

Alternatively, you can generate anomalies clickung the button Trigger anomaly and observe how the agents coordinate and repair.

Lessons Learned

This project has been built for embedded engineers who design, create and build industrial machines and want those machines to detect anomalies autonomously, reason, and get under maintenance at the edge without a cloud connection.

While this reference architecture uses simulated events and synthetic data for training the anomaly detection model, it is entirely possible to inject a real CAN-FD or other vibration sensors, point the UNS at your MQTT enterprise broker, and adapt the agent prompts to your planning rules. For this demo a single board can simulate the full stack but it can grow into a real line gateway making this a low-risk path from demonstration to production with Arduino VENTUNO Q.

The AI model delivers on-device anomaly detection, based on an Edge Impulse unsupervised machine learning model, that requires no labeled failure data. To re-train it, it only needs good vibration patterns in the training dataset.

Local LLM agents turn an anomaly detection into a decision and a production impact without leaving the machine, and the architecture keeps distributed between state, carried over MQTT, and tasks, handled via agent to agent communication.

Comments

Subscribe

Are you interested in bringing machine learning intelligence to your devices? We're happy to help.

Subscribe to our newsletter