reph

Templates · Education & classroom

Project proposal (synopsis) template

A project synopsis for approval: problem, objectives, literature survey, methodology, timeline, team roles and expected outcomes

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 team is proposing a final-year or course project and needs the guide or review panel to approve the problem, the plan and the split of work

Who it's for

StudentEducator

Part of a kit

Final-year project, step 1 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.

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

Department: B.Tech Electronics and Communication Engineering, final year · Author: Aditya Kulkarni · Date: 5 Aug 2026

Team Guide Review panel Domain
Aditya Kulkarni (22EC004), Nisha Pillai (22EC038), Farhan Sheikh (22EC051), Ishita Bose (22EC066) Dr. R. Subramanian Panel C IoT and machine learning

Abstract

Small workshops and pump houses run 1 to 5 HP induction motors until they fail, because vibration analysers cost more than the motors. Bearing faults cause a large share of these failures and show up in vibration weeks before a breakdown. We propose a clip-on sensor node built on an ESP32 and a MEMS accelerometer that samples vibration, extracts frequency features on the device and classifies the bearing as healthy, inner race fault or outer race fault with a small neural network. Alerts go to the owner's phone over Wi-Fi. We will train on the public Case Western Reserve University bearing dataset, then test on a 1 HP motor in the department's machines lab with seeded faults. We expect at least 90% accuracy on the lab motor at a hardware cost under ₹2,500 per node.

Problem statement

Motor owners in small industries find out a bearing has failed when the motor stops. An unplanned stop costs a day of production plus the rewinding bill when a seized bearing burns the winding. Industrial condition monitoring systems exist but cost well over ₹50,000 per machine and need a trained analyst. There is no affordable device that tells a non-expert "this bearing needs attention" early enough to plan the repair.

Objectives

  1. Build a sensor node that samples three-axis vibration at 3.2 kHz for under ₹2,500 in parts.
  2. Train a classifier that separates healthy, inner race and outer race faults with at least 95% accuracy on the CWRU dataset.
  3. Run the classifier on the ESP32 in under 200 ms per decision.
  4. Reach at least 90% accuracy on a real 1 HP motor with seeded bearing faults.
  5. Send a phone alert within one minute of a fault being detected.

Literature survey

# Work Approach Result Gap
[1] Randall and Antoni, 2011 Tutorial on envelope analysis and spectral methods for bearings The standard signal processing toolkit for bearing diagnosis Assumes an analyst reads the spectra
[2] Smith and Randall, 2015 Benchmark of classic diagnostic methods on the CWRU data Shows which CWRU recordings are clearly diagnosable and which are not Offline analysis on a PC, no edge deployment
[3] Case Western Reserve University Bearing Data Center Public vibration recordings with seeded bearing faults The most widely used training set for bearing fault classifiers Recorded on one test rig, so models need checking on other motors
[4] Warden and Situnayake, 2019 Running small neural networks on microcontrollers Practical methods for quantised models in tens of kilobytes General purpose, not specific to vibration

The gap: methods that work on a PC with a lab dataset, and tools for tiny models, but no tested low-cost device that combines them and is checked on a real motor outside the dataset's rig.

Proposed methodology

Mermaid diagram (drawn as a picture in reph)
flowchart LR
    A["ADXL345 accelerometer"] --> B["ESP32 sampling at 3.2 kHz"]
    B --> C["FFT and band energy features"]
    C --> D["Quantised neural network"]
    D --> E{"Fault?"}
    E -->|Yes| F["Phone alert over Wi-Fi"]
    E -->|No| B

Data and features

We will split the CWRU drive end recordings into one second windows and compute the energy in frequency bands around the shaft speed and the bearing defect frequencies, plus the RMS and kurtosis of each window. This gives about 40 features per window.

Model

A two layer dense network trained in TensorFlow, then quantised to 8-bit integers so it fits in the ESP32's memory. We will compare it with a random forest on the same features to check the network is worth its complexity.

Lab validation

The machines lab will lend us a 1 HP motor. We will seed faults by spark-eroding a 0.5 mm notch into the inner and outer race of spare 6205 bearings, then record 30 minutes of each condition at three loads.

Tools and resources

Item Purpose Cost
ESP32 DevKit Sampling, features, inference, Wi-Fi ₹450
ADXL345 module Three-axis vibration ₹350
Magnetic mount, enclosure, cable Clip-on fitting ₹700
Spare 6205 bearings (3) Seeded faults ₹900
CWRU dataset, TensorFlow Training Free

Total per node: ₹1,500, plus ₹900 of bearings for testing.

Timeline

Weeks Milestone Deliverable
1 to 3 Literature and dataset study Feature list, baseline on CWRU
4 to 7 Model training and comparison Model with at least 95% CWRU accuracy
8 to 10 Firmware and on-device inference Node classifying live data
11 to 13 Lab validation with seeded faults Accuracy on the 1 HP motor
14 to 15 Alerts, enclosure, report Working prototype and final report

Reviews: Review 1 in week 4, Review 2 in week 10, final review in week 15.

Team roles

Member Role Owns
Aditya Kulkarni Team lead Firmware and on-device inference
Nisha Pillai ML lead Features, training and model comparison
Farhan Sheikh Hardware Sensor mounting, enclosure, lab rig
Ishita Bose Testing and documentation Lab validation, phone alerts, report

Expected outcomes

  • A working clip-on node and its firmware, published as open source.
  • Accuracy of at least 95% on CWRU and 90% on the lab motor, with a confusion matrix for each.
  • A cost and power budget for one node.

Risks

Risk Likelihood Plan
Model trained on CWRU fails on the lab motor High Fine-tune on part of our own lab recordings and report both numbers
Seeding faults takes longer than planned Medium Book the workshop's spark eroder in week 6
ESP32 memory too small for the model Low Fall back to the random forest, which is smaller

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.

Approval

The template

Show the blank template

Project proposal (synopsis)

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

Team Guide Review panel Domain
[names and roll numbers] [guide name] [panel] [domain, for example IoT or machine learning]

Abstract

One paragraph of about 150 words: the problem, what you will build, how you will test it and what you expect to show.

Problem statement

Who has the problem, how often, what it costs them today, and why existing solutions fall short.

Objectives

Three to five objectives, each one specific and measurable.

  1. [objective]
  2. [objective]
  3. [objective]

Literature survey

Five to ten prior works: what each did, what it achieved, and the gap your project fills. Number them to match the references.

# Work Approach Result Gap
[1] [authors, year] [approach] [result] [gap]
[2] [authors, year] [approach] [result] [gap]

Proposed methodology

The pipeline from input to output, then a short paragraph on each stage.

Mermaid diagram (drawn as a picture in reph)
flowchart LR
    A["Data or input"] --> B["Processing"]
    B --> C["Model or core logic"]
    C --> D["Output and evaluation"]

[Stage one]

[description]

[Stage two]

[description]

Tools and resources

Hardware, software, datasets and lab access the project needs, with an estimated cost.

Item Purpose Cost
[item] [purpose] [cost]

Timeline

Milestones with dates, lined up with the department's review dates.

Weeks Milestone Deliverable
[weeks] [milestone] [deliverable]
[weeks] [milestone] [deliverable]

Team roles

Who owns what, so every member has a clear part to present at each review.

Member Role Owns
[name] [role] [area]

Expected outcomes

What will exist at the end, and the numbers that will show it works.

  • [outcome]

Risks

What could stop the project and what you will do if it happens.

Risk Likelihood Plan
[risk] [low, medium or high] [plan]

References

Numbered in the order they are cited, in one consistent style.

  1. [reference]
  2. [reference]

Approval

Filled in by the guide and the review panel.

Questions

How long should a synopsis be?
Four to six pages. The panel reads many of them, so lead with the problem and the objectives
Can the guide comment on it?
Share it with your guide as a commenter or editor. Comments sit next to the text they are about, and suggested edits wait for your team to accept them
How specific should the timeline be?
Week by week for the first month, then by milestone, with the review dates your department sets

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 proposal (synopsis)" with search_docs, then read it with read_doc. Draft the problem statement, objectives, methodology and timeline from the idea notes I paste. For the literature survey, list only papers I give you or that you can name with authors, venue and year, and mark any you are unsure of. 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