reph

Templates · Education & classroom

Project report template

A final-year or capstone project report: abstract, literature review, system design, implementation, results, conclusion, references and each member's contribution

Start with this template →Sign in

Opens on reph with the template ready to start. No account needed; sign in to keep your document.

Use it when

Your project is built and tested, and the team is writing the report the department and examiners will read and grade

Who it's for

StudentEducator

Part of a kit

Final-year project, step 3 of 4. A team project from start to defence: the synopsis, lab reports along the way, the final report and preparing for the viva.

Filled example

The template filled in for a made-up company, so you can see what good looks like.

Bearing fault detection for small induction motors on a low-cost edge device

Department: B.Tech Electronics and Communication Engineering, final year project report · Author: Aditya Kulkarni · Date: 24 Apr 2027

Team Guide Academic year
Aditya Kulkarni (22EC004), Nisha Pillai (22EC038), Farhan Sheikh (22EC051), Ishita Bose (22EC066) Dr. R. Subramanian 2026 to 2027

Abstract

Small workshops run induction motors until they fail, because vibration monitoring equipment costs more than the motors. We built a clip-on sensor node from an ESP32 and an ADXL345 accelerometer that classifies a motor's bearing as healthy, inner race fault or outer race fault, entirely on the device, and sends a phone alert when it finds a fault. The node computes 40 frequency band and statistical features from each one second window of vibration and runs an 8-bit quantised neural network of 11 KB. Trained on the Case Western Reserve University (CWRU) bearing dataset, the model reached 97.8% accuracy on held-out CWRU data. On a 1 HP motor in our machines lab, with faults seeded into spare bearings, accuracy dropped to 88.4%, and fine-tuning on 20% of our own recordings raised it to 93.1%, above the 90% target. Each decision takes 38 ms on the ESP32, an alert reaches the phone in 22 seconds on average, and a node costs ₹1,500 in parts. The results show that useful bearing fault detection is possible at a price a small workshop can pay, provided the model is tuned on the motor it will watch.

1. Introduction

Bearing faults are one of the most common causes of induction motor failure, and they show up in vibration well before a motor seizes. Industrial monitoring systems detect them but cost tens of thousands of rupees per machine. This project set out to detect the common bearing faults with a device costing under ₹2,500.

1.1 Objectives

Objective Target Achieved
Node parts cost Under ₹2,500 ₹1,500 (met)
Accuracy on CWRU test data At least 95% 97.8% (met)
On-device decision time Under 200 ms 38 ms (met)
Accuracy on the lab motor At least 90% 93.1% after fine-tuning (met)
Alert latency Under 60 s 22 s mean (met)

2. Literature review

Envelope analysis and spectral methods are the standard way to diagnose bearings, and Randall and Antoni's tutorial [1] describes them in detail, but they assume a trained analyst reads the spectra. The CWRU dataset [3] made machine learning approaches easy to compare, and Smith and Randall's benchmark [2] showed that some CWRU recordings are much harder to diagnose than others, a warning against trusting accuracy figures from that dataset alone. Work on running small neural networks on microcontrollers [4] showed that quantised models of tens of kilobytes are practical. No work we found combined these into a low-cost device and tested it on a motor other than the CWRU rig, which is the gap this project fills.

3. System design

Mermaid diagram (drawn as a picture in reph)
flowchart TB
    subgraph node1 [Sensor node on the motor]
        A["ADXL345 accelerometer, 3.2 kHz"] --> B["ESP32: windowing and FFT"]
        B --> C["40 features per window"]
        C --> D["Quantised neural network, 11 KB"]
    end
    D --> E["Wi-Fi alert service"]
    E --> F["Owner's phone"]

3.1 Sensing

The ADXL345 is held to the motor's drive end bearing housing by a magnetic mount and samples three axes at 3.2 kHz over SPI. The ESP32 collects one second windows with 50% overlap.

3.2 Features and model

For each window the ESP32 computes an FFT and the energy in bands around the shaft speed and the bearing defect frequencies, plus the RMS and kurtosis of each axis, 40 features in all. A dense network with two hidden layers of 32 and 16 units classifies the window. A fault is reported only when five windows in a row agree, which removed almost all false alarms in testing.

4. Implementation

Component Choice Why
Microcontroller ESP32 DevKit Two cores, Wi-Fi, enough RAM for the FFT and model
Accelerometer ADXL345 3.2 kHz output rate covers the defect frequencies of a 6205 bearing at 1,440 rpm
Model framework TensorFlow Lite for Microcontrollers Runs 8-bit models with no operating system
Alerts MQTT to a small server, then a push notification Works on the workshop's existing Wi-Fi

5. Results

Faults were seeded by spark-eroding a 0.5 mm notch into the inner race of one spare 6205 bearing and the outer race of another. We recorded 30 minutes of each condition at no load, half load and full load. 20% of the recordings were used for fine-tuning, and 600 windows per condition were drawn from the rest as the test set.

Test Metric Target Result
CWRU held-out data Accuracy 95% 97.8%
Lab motor, CWRU model only Accuracy 90% 88.4%
Lab motor, after fine-tuning Accuracy 90% 93.1%
On-device inference Time per decision 200 ms 38 ms
Alerts Mean latency 60 s 22 s
Accuracy against target (%)
Accuracy against target (%)020406080100CWRU held-outLab motor before tuningLab motor after tuningCWRU held-out · target: 95CWRU held-out · result: 97.8Lab motor before tuning · target: 90Lab motor before tuning · result: 88.4Lab motor after tuning · target: 90Lab motor after tuning · result: 93.1
  • target
  • result
View data
testtargetresult
CWRU held-out9597.8
Lab motor before tuning9088.4
Lab motor after tuning9093.1

Confusion matrix on the lab motor after fine-tuning (rows are the true condition):

True condition Predicted healthy Predicted inner race Predicted outer race
Healthy (600) 578 8 14
Inner race (600) 25 545 30
Outer race (600) 16 31 553

6. Discussion

The drop from 97.8% on CWRU to 88.4% on our motor is the main finding. Our motor runs at a different speed and load from the CWRU rig, so the defect frequencies move and the band energies the model learned shift with them. Fine-tuning on 20% of our own recordings recovered most of the loss. Most remaining errors are between inner and outer race faults at no load, where the vibration is weakest. The node cannot yet tell how severe a fault is, only that one is present.

7. Conclusion

We built and tested a ₹1,500 sensor node that detects inner and outer race bearing faults on a real motor with 93.1% accuracy, deciding in 38 ms on the device and alerting the owner in about 22 seconds. All five objectives were met, with the caveat that the model must be fine-tuned on recordings from the motor it watches.

8. Future work

  • Normalise features by shaft speed so one model works across motors without fine-tuning.
  • Estimate fault severity from notch sizes of 0.2, 0.5 and 1.0 mm.
  • Run the node from a battery and measure how long it lasts at one decision per minute.

References

  1. R. B. Randall and J. Antoni, "Rolling element bearing diagnostics: A tutorial," Mechanical Systems and Signal Processing, vol. 25, no. 2, pp. 485 to 520, 2011.
  2. W. A. Smith and R. B. Randall, "Rolling element bearing diagnostics using the Case Western Reserve University data: A benchmark study," Mechanical Systems and Signal Processing, vol. 64 to 65, pp. 100 to 131, 2015.
  3. Case Western Reserve University Bearing Data Center, bearing vibration dataset.
  4. P. Warden and D. Situnayake, TinyML, O'Reilly Media, 2019.

Appendix A: Individual contributions

Member Contribution Share
Aditya Kulkarni Firmware, FFT and feature code, on-device inference, Sections 3 and 4 25%
Nisha Pillai Feature design, training, fine-tuning and model comparison, Section 5 25%
Farhan Sheikh Sensor mount, enclosure, lab rig and fault seeding, Section 3.1 25%
Ishita Bose Test plan, lab recordings, alert service, Sections 1, 2 and 6 25%

The template

Show the blank template

Project report

Department: [department and programme] · Author: [your name] · Date: [date]

Team Guide Academic year
[names and roll numbers] [guide name] [year]

Abstract

About 250 words: the problem, what you built, how you tested it, the key numbers and what they mean.

1. Introduction

The problem, why it matters, and the objectives from your synopsis, each marked met or not met.

1.1 Objectives

Objective Target Achieved
[objective] [target] [result]

2. Literature review

Prior work grouped by approach, cited as [1], [2], ending with the gap this project fills.

3. System design

The architecture as a diagram, then each block explained.

Mermaid diagram (drawn as a picture in reph)
flowchart TB
    A["Input layer"] --> B["Processing layer"]
    B --> C["Application layer"]
    C --> D["User"]

3.1 [Block one]

[description]

3.2 [Block two]

[description]

4. Implementation

Hardware, software and the decisions that mattered, with the reason for each.

Component Choice Why
[component] [choice] [reason]

5. Results

Test setup first, then the numbers in a table and a chart, compared with your targets.

Test Metric Target Result
[test] [metric] [target] [result]
Result against target
Result against target00.20.40.60.81Test 1Test 2Test 1 · target: 0Test 1 · result: 0Test 2 · target: 0Test 2 · result: 0
  • target
  • result
View data
testtargetresult
Test 100
Test 200

6. Discussion

What the results mean, where the system falls short and why.

7. Conclusion

What the project achieved, in one paragraph.

8. Future work

Concrete next steps another team could pick up.

  • [next step]

References

Numbered in the order first cited in the text.

  1. [reference]
  2. [reference]

Appendix A: Individual contributions

Each member's work, agreed by the whole team.

Member Contribution Share
[name] [what they did] [percent]

Questions

Can four people write it at once?
Yes. Everyone edits the same document live, comments go next to the text they are about, and version history shows who saved each version
How do we show who did what?
Fill in the contribution table, and keep version history, which records who saved each version
What if our results missed the target?
Report them as they are and explain why in the discussion. Examiners mark the reasoning, not only the number

Fill it with your agent

Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.

Find my reph doc "Project report" with search_docs, then read it with read_doc. Draft the abstract, design, implementation and results sections from our synopsis, code README and test logs, which I will paste. Use only numbers from those logs and never round a result up. Keep references numbered [1], [2] in the order cited. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question with add_comment quoting that section's heading line, then call request_review with a one-line summary.

Related templates

Start with this template →Sign in