How to achieve cost-effective predictive maintenance with the Arduino® UNO™ Q board
Most machines warn you before they fail. A motor begins to vibrate differently. A pump slowly drifts out of balance. A bearing develops a new mechanical signature. A cooling fan starts producing frequencies that were not present during normal operation.
These changes can appear well before a complete breakdown. The challenge is detecting them early, reliably, and at a cost that makes monitoring practical across more than just the factory’s most expensive machines.
UNO Q provides a flexible platform for building a compact predictive maintenance node that collects vibration data, runs a machine learning model locally, and turns unusual machine behavior into actionable alerts. The result is a practical way to begin monitoring motors, pumps, fans, bearings, compressors, and other rotating equipment without immediately deploying a complex cloud infrastructure.
Pickin’ up good (and bad!) vibrations
Vibration is one of the most useful signals for understanding the condition of rotating machinery. When a machine is operating normally, its motor, bearings, shafts, and mechanical components produce a relatively consistent vibration pattern. Changes in alignment, balance, friction, mounting, or component wear can alter that pattern.
A traditional monitoring system might trigger an alert whenever vibration exceeds a predefined value. That approach can be useful, but machines rarely operate under perfectly fixed conditions. Speed, load, product type, temperature, mounting position, and operating mode can all influence the vibration signal. This is where anomaly detection becomes especially valuable.
A vibration sensor does not automatically identify every mechanical fault. It provides the raw signal from which meaningful patterns can be extracted. UNO Q – perhaps starting with an Arduino® Modulino™ Movement sensor and later adding a more precise vibration sensor – can capture acceleration data across three axes. Mounted securely on a motor or pump housing, it can record how the machine behaves during normal operation and how that behavior changes when a fault begins to develop.
The sensor can capture more than a single vibration value. It can record a time series that describes the direction, amplitude, and frequency of the movement. This gives a machine learning model more information than a simple threshold alarm.
A team can collect representative data from a healthy machine, train an anomaly detection model, and deploy it to the edge. When the model sees a vibration pattern that is sufficiently different from what it learned, it produces a higher anomaly score.
The system does not need to know the name of every possible fault before deployment. It can begin by answering a more practical question: “Is this machine still behaving as expected?”
See this pattern in action: This sense-infer-respond loop is exactly what’s demonstrated in the AI Guard Demo with Arduino UNO Q, Modulino sensors, and local NPU face recognition, published on Arduino® Project Hub by user shivaylamba. The project is built around face recognition, but the underlying architecture – a Modulino sensor triggering local inference, which then drives a physical response – is the same blueprint a vibration-based anomaly detector would follow, just with different sensors and a different model.
Or check out how AudioLog uses Arduino UNO Q Edge AI to “listen” to machines, detecting early signs of failure to prevent costly industrial downtime.
From raw data to business intelligence
A first predictive maintenance project can begin with one machine and a limited number of operating conditions.
The out-of-the-box example shipped with Arduino® App Lab is a great starting point.
The Modulino Movement sensor is mounted firmly on the equipment. UNO Q records acceleration data while the machine is idle, starting, running normally, operating under different loads, and shutting down.
The microcontroller side manages sensor acquisition, sending the data to the Linux side that manages data logging, model execution, dashboards.
Collecting this range of normal behavior is important. A model trained on only one operating condition may incorrectly classify a legitimate speed or load change as a fault.
Depending on the application, the project can use classification or anomaly detection.
Classification is useful when the team already has examples of known conditions, such as normal operation, imbalance, misalignment, or a loose mounting.
Anomaly detection is useful when fault data is limited or when intentionally damaging equipment to create training examples would be unsafe or impractical. In this case, the model learns normal behavior and highlights signals that do not fit that baseline.
Worth a look: For a hands-on look at what running ML locally on UNO Q actually feels like in practice, check out Running ML/AI on Arduino UNO Q on Hackster. It’s a capability demo rather than a predictive maintenance project specifically, but it walks through the App Lab sample apps and on-device inference experience that the classification and anomaly detection workflows above are built on top of.
Looking for even more inspiration? Check out this predictive maintenance project that reads automotive CAN bus raw data to determine systematic drifts early, and alert you when the line is not in sync with specs.
A large model is not necessarily a better model
The model for a vibration monitoring application has a narrow job. It does not need to understand images, natural language, or hundreds of unrelated machine types. It only needs to distinguish the relevant operating patterns of the equipment being monitored. This focus on smaller, task-specific models helps make always-on monitoring practical.
Continuous vibration monitoring can generate a large amount of data, but sending every raw sample to the cloud is not always necessary – especially considering it can increase bandwidth consumption, introduce recurring infrastructure costs, and make the monitoring system dependent on network availability.
UNO Q processes vibration windows locally and stores or transmit only useful information, such as the current health state, anomaly score, operating mode, timestamp, or alert event. A local dashboard can show recent machine behavior and event history. When an anomaly exceeds a validated threshold for a defined period, the system can activate a warning light, sound a buzzer, log the event, or send a message to a maintenance service.
Cloud connectivity can still be added when it provides value. The difference is that the core detection process does not need to stop when the internet connection is unavailable.
Going deeper: Edge Impulse has specific predictive maintenance guidance around monitoring equipment while it runs, so service teams can act before failure occurs. Its optimization tools are designed precisely for constrained edge deployments like this one: quantized int8 models and RAM-optimized compilation matter here because always-on monitoring needs lower compute, lower memory use, and better power behavior over the long run.
The real value of predictive maintenance
Predictive maintenance works when people are given enough warning to inspect a machine before an unexpected stoppage: there still has to be time to act. The great news is UNO Q now brings the sensing, local intelligence, Linux applications, connectivity, and machine-facing control needed to build that workflow on a single platform. It allows teams to start with a simple question – “Is this machine still behaving normally?” – and to develop the answer into a scalable maintenance system.
Ready to never be caught off-guard by a faulty machine or worn-down part again? Build a custom predictive maintenance system that you can easily train on your specific data, with UNO Q and Arduino App Lab.
UNO Q is available to order from the Arduino Store as well as DigiKey, Farnell, Mouser, Newark, RS Components, and Robu.in; along with our other authorized distributors and resellers.
Arduino, UNO, Modulino and the Arduino logo are trademarks or registered trademarks of Arduino S.r.l.