Inspiration

I’ve mostly worked on game projects before, where you deal with player input, feedback loops, and timing. When I saw this dataset, it felt similar except instead of a player, it was a machine slowly wearing out. I liked the idea of turning messy industrial signals into something simple that tells you “okay, it’s time to change the blade” instead of dumping raw numbers at people.

What it does

• Takes raw motor torque data from an industrial machine
• Calculates a fatigue value (Φ) for every cut
• Tracks how that value grows over time
• Uses a simple k-NN model to decide whether the blade is still okay, needs attention, or should be stopped
• Shows the result on a small live dashboard instead of logs or charts

The goal is not perfect prediction, just clear decisions.

How we built it

• Started by loading the raw CSV files and just trying to understand what each signal meant
• Focused on motor torque because it showed clear patterns per cut
• Computed Φ using the area under the torque curve for each cut
• Added slope and acceleration to capture how fast wear is changing
• Trained a one-class k-NN model on healthy data
• Built a Gradio interface so anyone can play with the inputs

A lot of this were trial and error!

Challenges we ran into

• The dataset is huge and messy, so loading and cleaning it took way longer than expected
• Many models were overkill and didn’t actually help
• Getting the dashboard to stop showing “100% bad” for every input took debugging
• Understanding what not to include in the repo was confusing at first

Accomplishments that we're proud of

• Got the model to behave sensibly instead of flagging everything as broken
• Built a working live dashboard within the 48-hour window
• Managed to process data from multiple blade runs without manually cleaning each file
• Kept the approach simple and physics-based instead of forcing a complex ML model
• Took the project all the way from raw CSV files to a deployed demo

What we learned

• Simple models can be more useful than complex ones
• Physics intuition matters more than model complexity
• Deployment and packaging are real skills
• Real data is always worse than tutorial data
• Explaining your work clearly is just as important as building it

What's next for CutBeforeBreak

• Connect it to real sensors (like STM32 or PLC data)
• Improve how Φ is normalized across different machines
• Add better visual feedback instead of only text
• Test it on other types of industrial components

Built With

Share this project:

Updates