See which robot needs help, why, and how to fix it, before a small issue turns into costly downtime.
The robot is fighting the steering the whole way
It’s working 15% harder to drive straight than it was last week
A robot goes down mid-task and its output goes to zero. Everything that depended on it slows, and the day's productivity goes with it.
A robot down in the field isn't an isolated problem. Tasks get reassigned, routes back up, and someone has to drive out and deal with it.
By the time a reading finally crosses a limit, the small fault has become a replacement, and a scheduled stop has become an unplanned one.
Robots compensate for their own faults. Performance looks fine, tasks keep completing, and nothing in your fleet software changes until the robot fails.
An edge-native fault detection system that runs on the robot itself.
Faros watches how sensor readings move together then says what changed and how to fix it before the robot fails.
Faros taps into the robot's own signals: motors, sensors and telemetry. It reads them right on the hardware, in real time.
It builds a model of what normal looks like for each individual robot.
When behaviour drifts from normal, Faros flags it early, before it becomes a breakdown in the field.
Every alert comes with the why and the what to do. Your team fixes it fast and efficiently.
No streaming data offsite, no cloud dependency. It works where the robot works.
Record the robot working normally and that becomes its baseline.
It reads what the robot already publishes. No extra instrumentation, no retrofit.
Minimal CPU, minimal memory, no strain on bandwidth. Your robot's real workload always comes first.
It watches how the readings move together. Any brand, any model.
We tested Faros on a Raspberry Pi 4, which is about as small a computer as you would ever run it on. It barely used any of the board. If it runs comfortably there, it will run on whatever your robot already has. No extra hardware, no GPU.
| Resource | Faros uses | Out of | Total used in % |
|---|---|---|---|
| Processor | 12% of one coreof 4 cores | 4 cores | 3% |
| Memory | 203 MBof 4 GB | 4 GB | 5% |
| Time, each second | 34 ms62 ms at worstof 1,000 ms | 1,000 ms | 3% |
Tested on a Raspberry Pi 4, 4× Cortex-A72 @ 1.5 GHz, 4 GB RAM
The demo uses a drone because a failing motor is easy to picture. Nothing about the way it works is specific to drones.
Catch faults before they stop the robot in production.