AI & ML

Predictive Maintenance from Machine Vibration Data

Detect developing faults in rotating machinery from vibration and current signals before failure, using public bearing datasets and, ideally, a small rig of your own. A classic industrial problem where the modelling is tractable and the evaluation is unusually honest.

Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

1 semester, 2 students

Deliverables

5 to ship

3 optional extras

Suggested stack

Pythonscikit-learnPyTorchInfluxDBGrafana
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • Signal processing pipeline producing time and frequency domain features from raw vibration data
  • Fault classification model evaluated on operating conditions absent from training
  • Remaining useful life estimation with error reported in cycles or hours
  • Dashboard showing live signal, current health assessment and alert history
  • Analysis of how early a developing fault is reliably detected before failure

If you have time left

  • A physical test rig with an accelerometer and deliberately induced bearing faults
  • Anomaly detection for fault types absent from the training data
  • Model running on a microcontroller near the machine rather than in the cloud

The problem

Unplanned machine failure is expensive, and the signals that precede it are usually present in vibration data days or weeks in advance. This is a well studied problem with genuinely good public datasets, which makes it a reliable choice for a project that has to produce results on a schedule.

What you build

A feature extraction pipeline over vibration signals, a classifier that identifies fault type, a remaining useful life estimator, and a monitoring dashboard.

Why the domain features matter

The frequency domain is where the information lives. Bearing faults produce characteristic frequencies determined by the geometry of the bearing, and computing those explicitly gives a small model excellent performance. Throwing raw signals at a large network is the worse approach and a very common student mistake.

The evaluation trap to avoid

Splitting a single continuous recording randomly into train and test leaks information and produces near perfect accuracy that means nothing. Split by machine, by run, or by operating condition, and say clearly in your report which you did.

Adding your own rig

If you can build even a simple motor with an accelerometer and induce a fault deliberately, do it. Results on data you collected yourself are worth far more than another run on a public benchmark, and it demonstrates end to end capability.

Scope warning

One machine type. Bearings are the sensible choice because the physics is documented and the datasets exist.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Get guidance
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.

Follow along

New writing, resources and project ideas land here first.