Intelligence that understands the machine it touches.
We are developing a self-configuring edge-AI platform that senses connected equipment, learns its operating behaviour and turns physical signals into actionable intelligence, with minimal setup.
Prototype development stage · Monitoring and recommendations only · No autonomous machine control
Water Pump 01
Attention recommendedVibration and surface temperature rising together while flow falls.
Concept enclosure and illustrative output
Bench demo
Learn a pump, then catch a fault.
The clearest way to judge this platform is to watch it meet a machine it has never seen. Our first demonstration follows one sequence, end to end.
- 1The device is clamped onto a running bench pump. No PLC, no tag mapping, no commissioning file.
- 2It watches normal operation and builds a baseline for that specific pump.
- 3We induce a real fault by closing the inlet valve, so the pump starts running dry.
- 4The alert arrives in plain language, with what changed and what to check first.
- 01Connect
- 02Learn
- 03Detect
- 04Explain
Illustrative animation — not recorded footage
The bench prototype is being instrumented now. Recorded footage will replace this animation, and partners can see a live session before it is published.
What is Physical AI
AI is moving beyond the screen.
Traditional AI works mainly with digital information. Physical AI combines sensors, edge computing, specialised models and real-world equipment. It observes how machines behave, understands changing conditions and produces decisions grounded in the physical world.
Software AI
- Reads digital inputs
- Produces digital outputs
- Operates inside applications
Physical AI
- Senses real-world conditions
- Understands machine behaviour
- Supports physical decisions and actions
The problem
Machines generate signals. Most businesses cannot understand them.
Small factories, farms, buildings and commercial facilities often operate critical motors and pumps without continuous intelligence.
Unexpected equipment failure
A motor or pump usually degrades for days or weeks before it stops. Without continuous observation, the first signal is the outage itself.
Manual, periodic inspections
Walk-around checks capture a moment, not a trend. Conditions that appear between rounds are easy to miss entirely.
Fixed thresholds miss changing behaviour
A single alarm limit cannot describe a machine whose normal load shifts with season, duty cycle and site conditions.
Machine-specific integrations are expensive
Bespoke wiring, tag mapping and dashboard work for every installation makes small deployments hard to justify.
The product
Meet Raone Physical AI Edge
A compact edge device designed to observe a machine, learn its baseline and identify meaningful changes without requiring a custom AI project for every installation.
- Power input
- Isolated DC supply
- RS-485 / Modbus
- Screw terminal
- Ethernet
- Local network / gateway
- USB-C service port
- Commissioning and diagnostics
- Sensor inputs
- Current, vibration, temperature, acoustic
- Antenna
- Optional wireless connectivity
Designed for a wall-mounted or DIN-rail cabinet position, in a matte graphite industrial enclosure with a status light strip and clearly labelled connectors.
Concept enclosure — MVP industrial design
Inside the device
Built to sense, learn and explain.
The proposed internal architecture separates timing-sensitive acquisition from the compute that interprets it, so each part can be validated on its own.
Exploded concept view
Edge compute module
Runs signal processing, baseline models and anomaly detection locally.
ESP32-S3 sensor controller
Deterministic timing for sampling current, vibration and acoustic channels.
Signal-conditioning board
Filtering, amplification and protection ahead of the analogue front end.
RS-485 / Modbus interface
Reads machine-side registers where an interface is already available.
Connectivity module
Ethernet plus optional wireless for remote access and fleet services.
Local encrypted storage
Buffers signal history so monitoring survives connectivity gaps.
Isolated power management
Galvanic isolation between machine-side sensing and logic.
Thermal management
Passive dissipation sized for enclosed industrial cabinets.
Expansion interface
Header for additional sensors such as pressure or water flow.
Concept architecture. Components may change during prototype validation.
How it works
Five steps from installation to insight
- 01
Connect
Attach non-invasive sensors, or connect through an available machine interface such as RS-485 / Modbus.
- 02
Discover
The system identifies which signals are present, which protocols respond and which operating states exist.
- 03
Learn
It observes normal operation over time and establishes a baseline specific to that individual machine.
- 04
Detect
Signal-processing and anomaly models identify deviations that are meaningful rather than merely noisy.
- 05
Explain
Structured findings become readable diagnostics, recommended actions and alerts for the people on site.
First MVP
Starting with the machines that keep everything moving.
Electric motors and water pumps are the first development target for four reasons.
- Used across factories, farms, buildings and commercial facilities.
- Failures cause downtime and operational disruption.
- Current, vibration and temperature provide strong health signals.
- Monitoring can be installed without taking over machine control.
- Current clamp
- Non-invasive load and start-stop behaviour
- Vibration sensor
- Bearing, alignment and imbalance signatures
- Temperature sensor
- Surface temperature of housing and motor body
- Acoustic sensor
- Airborne noise pattern during operation
- Flow or pressure
- Optional, for dry-running and blockage context
Concept sensing diagram
Target MVP detection capabilities
Dry-running risk
Load and flow signatures that suggest a pump is running without water.
Abnormal vibration
Amplitude or spectral change against the learned running baseline.
Motor overheating
Surface temperature rising beyond the machine’s own normal envelope.
Unusual current consumption
Load drift that does not match the established duty pattern.
Excessive start-stop cycles
Cycling behaviour that shortens equipment life over time.
Developing bearing fault
Combined vibration and acoustic change over successive run cycles.
These are development targets for the first MVP, not commercially validated results.
Example output
What an alert is intended to look like
The explanation layer receives structured findings, not raw signals. Its job is to state what changed, how far it moved from the learned baseline, and what a technician should check first.
Equipment
Water Pump 01
Observed changes
- Vibration
- +32% above learned baseline
- Surface temperature
- +9 °C
- Water flow
- −21%
- Condition duration
- 46 minutes
AI assessment
The combination of increased vibration, rising temperature and reduced flow may indicate bearing wear, shaft misalignment or an obstruction.
Recommended action
Inspect the pump assembly and water inlet before continued heavy operation.
Illustrative diagnostic output
Architecture
Intelligence across the edge and cloud.
- 01
Machine and sensors
Motor, pump and the non-invasive sensors attached to it.
- 02
Sensor interface
Conditioning, isolation and synchronised sampling.
- 03
Edge signal processing
Feature extraction close to the machine, in real time.
- 04
Baseline and anomaly detection
Per-machine normal behaviour and deviation scoring.
- 05
Explanation layer
Structured findings turned into readable diagnostics.
- 06
Dashboard, WhatsApp, API
Delivery to the people and systems that act on it.
Time-sensitive signal processing happens at the edge.
Equipment can continue monitoring during limited connectivity.
Cloud services provide fleet learning, device management and advanced explanations.
Safety rules remain separate from generative-AI output.
Two compute layers, one boundary
The device is designed around two separate compute domains. Detection is deterministic and fast. Language is separate, slower and advisory. The boundary between them is what keeps a language model out of the control path.
Layer 1
Deterministic detection
- Runs on
- MCU-class sensor controller inside the device
- Timescale
- Microseconds to milliseconds
- Responsible for
- Sampling, filtering, feature extraction, baseline comparison, anomaly scoring and any future interlocks
- Behaviour
- Same input, same output, every time
Never: generates language, and never depends on a model’s wording to reach a conclusion.
Layer 2
Language and explanation
- Runs on
- A separate NPU-class edge processor, with cloud assistance when available
- Timescale
- Seconds
- Responsible for
- Turning structured findings into diagnosis, recommended actions and answers to plain-language questions
- Behaviour
- Advisory, reviewable, and safe to be wrong about wording
Never: sees raw samples, and never issues a command to the machine.
Compute classes are candidates for prototype validation, not selected parts. The MCU-class controller cannot host a language model, so the two domains are planned as separate silicon inside one enclosure.
Generative AI does not directly control the machine in the monitoring MVP.
Why Raonebytes
Hardware, embedded systems and AI, developed together.
Raonebytes’ prototyping experience provides the foundation to design the electronics, enclosure, sensor integrations and embedded software as one coordinated product.
Hardware prototyping
Schematic design, multi-layer PCB layout, assembly and bring-up handled in-house.
Embedded and edge systems
Bare-metal and RTOS firmware, sensor drivers, timing-sensitive acquisition and connectivity stacks.
AI model integration
Signal features, anomaly models and a separate explanation layer, deployed on constrained hardware.
Pilot-to-product engineering
Enclosure design, DFM-ready files and manufacturing handoff, the path we already run for client hardware.
See our engineering case studies for the hardware work this platform builds on.
Development roadmap
Where the platform is today, and where it goes next
- Stage 01
Working bench prototype
Current focusSensor integration, data capture and equipment-state recognition on a bench setup.
- Stage 02
Field MVP
Baseline learning, anomaly detection, alerting and a pilot enclosure installed on real equipment.
- Stage 03
Multi-machine intelligence
Support for additional pumps, motors and industrial protocols across a site.
- Stage 04
Assisted machine actions
Human-approved recommendations and controlled actions within defined limits.
- Stage 05
Autonomous physical AI
Safe operation inside certified boundaries and explicit permissions.
Where this goes
A starting point, not the destination.
Motors and pumps are the first machines we are teaching the platform to understand. The same three layers, signal intelligence, equipment intelligence and explanation, are intended to generalise to the everyday devices and machines around them. Our direction is a plug-and-play module that discovers what it is connected to and configures itself, so making a machine AI-ready looks more like plugging something in than commissioning a bespoke project.
Same platform, more machines
After the first MVP we intend to experiment with further equipment types, starting with machines that share similar electrical and mechanical signatures.
Plug-and-play by design
The goal is a module that identifies the signals available to it and sets up its own baseline, instead of a machine-specific integration every time.
Everyday equipment, not just plant
The same approach is intended to reach the day-to-day devices and machines that no one monitors continuously today.
Forward-looking direction, not committed product scope. Development is currently focused on the motor and pump MVP.
Get involved
Help us build the intelligence layer for physical machines.
Raonebytes is preparing the first working prototype and seeking conversations with investors, industrial partners and pilot customers who share our vision for accessible Physical AI.
Early-stage investment
Back the prototype phase and the engineering team building the platform end to end.
Industrial pilot partnerships
Host a pilot installation on your motors or pumps and shape the detections that matter to you.
Hardware and AI ecosystem
Sensor, silicon, connectivity and model partners who want a reference deployment at the edge.
Start a conversation
Tell us whether you are interested in investment, a pilot installation or a technology partnership, and we will follow up within 24 hours.
FAQ
Common questions
What makes this different from a traditional IoT monitor?
Traditional IoT systems commonly depend on predefined dashboards and fixed thresholds. The proposed platform is intended to learn an individual machine’s operating baseline and interpret changing combinations of signals.
Does the LLM control the machine?
No. In the monitoring MVP, deterministic signal processing and anomaly models analyse equipment behaviour. The LLM explains structured findings and recommended actions.
Does the device require an internet connection?
The intended architecture supports local monitoring and data collection at the edge. Connectivity is used for remote access, fleet intelligence and advanced services.
What equipment will the first MVP support?
The first development target is electric motors and water pumps using non-invasive current, vibration, temperature and acoustic sensing.
Is the product commercially available?
No. The product is currently in prototype development. Raonebytes is inviting investor, technology-partner and pilot discussions.