Telltale

Inspiration

Machines tell you they are failing before they fail. A bolt comes loose and the vibration changes. A belt starts to slip and the motor draws less current. The motor begins to stall, and by the time anyone notices, the equipment is damaged. The signs are there, but you have to know what you are listening for, and most people do not.

Industrial predictive maintenance solves this, but it costs lots of money and needs a fleet of identical machines to learn from. Student teams, makerspaces and small shops just run their equipment until it dies. We are on a rocket team and a Formula SAE team, so that is our own problem.

What it does

Telltale is a benchtop rig that learns one machine instead of a thousand. Two sensors watch it, current and vibration, and a model running locally on an ASUS Ascent GX10 learns what that specific machine looks like when it is healthy.

From then on it is never idle. Every moment the rig is running it compares what it sees against that baseline, so it is not waiting for a number to cross a limit someone guessed at. It is asking whether this machine still looks like itself, and the instant it does not, it names what changed: a loose fastener, a slipping belt, or a stall.

All of it runs offline, because a fault you catch three seconds late is a fault you did not catch.

How we built it

Everything on site, from loose parts, inside the build window.

The rig is all off the shelf. A 12 V gearmotor drives a GT2 belt to a shaft in two pillow block bearings, with the motor on slots so belt tension can be released live, and one M4 thumb screw standing in for the fastener that works loose.

An ESP32 reads an INA226 for current and an MPU6050 for vibration over one I2C bus, samples both on a single fixed clock, and streams one timestamped line over USB to the GX10. Features come off a rolling window and the model scores them there.

Challenges we ran into

Clock discipline. Two sensors at different natural rates on one timeline will silently drift, and then every result downstream is wrong with nothing to tell you why. Getting both onto one trustworthy clock mattered more than any modelling decision we made.

Sensor range. The INA226's shunt saturates near 0.8 A, so a hard stall pins the reading instead of showing a curve. We changed the fault rather than the sensor. A gentle brake gives a real in-range trace and is a more realistic failure anyway.

Mounting. A sensor that can move measures its own movement. The IMU had to be rigid and on the output bearing block, the exact part the thumb screw releases.

Accomplishments we're proud of

A physical machine that moves, breaks on command, and gets caught by a model running on one box with the network off. And a number behind it rather than a vibe.

What we learned

How much of this problem is mechanical and electrical rather than modelling. The features separated the faults on a hand-drawn plot before any model existed, and that was the signal the rig was right.

What's next for Telltale

Point it at a machine it has never seen. Watch two minutes of healthy operation, build a baseline, then flag and describe what deviates. That is anomaly detection rather than named classification, and it is the honest version of "works on anything".