VibraLens

Inspiration

A phone camera is easy to find. Dedicated vibration-monitoring equipment is not always within reach of a small workshop.

I wanted to explore whether an ordinary slow-motion recording could help someone notice a change in a machine’s vibration and decide when it deserves a closer inspection.

But getting a number from a video is only part of the problem. Camera shake, poor focus and slow-motion playback can produce a convincing result that is wrong. That became the main idea behind VibraLens: check whether the evidence is usable before offering advice.

What it does

VibraLens turns an original slow-motion phone video into a vibration-screening workflow.

The recording includes a printed marker on the machine’s stationary housing and a separate reference marker on an independent structure. OpenCV tracks their movement, compensates for camera motion and estimates the vibration frequency.

From there, the system decides what evidence it needs next. It can:

Ask for a closer or clearer recording.
Request the machine’s rated speed to help identify the shaft frequency.
Compare the result with a compatible earlier recording.
Draft an inspection work order that requires supervisor approval.

Each decision has a visible trace, so the user can see why it happened. Nothing controls the machine automatically. Markers must be placed with the equipment switched off.

How I built it

OpenCV 5 handles ArUco marker detection, subpixel corner tracking, camera-motion compensation and geometric scaling. NumPy and SciPy handle the frequency and signal analysis.

I built the application with Python, FastAPI and a JavaScript interface. The deployed version runs its OpenCV processing on AWS EC2, stores recordings privately in S3, and keeps sessions, readings and processing jobs in DynamoDB. CloudFront provides the public HTTPS endpoint, while SNS is configured for supervisor notifications.

The demonstrated agent uses a deterministic policy: its available actions depend on the current evidence. There is also an optional Bedrock integration, but the verified demonstrations use the rule planner.

The hardest parts

The biggest surprise was how easily slow-motion timing can mislead the analysis. A video captured at 240 frames per second can be saved for playback at 30. Using playback timing would make the measured frequency eight times too low.

I added timing checks and made the system refuse recordings when it cannot establish a usable capture rate.

Small movements were another challenge. Compression can underestimate motion that occupies only a fraction of a pixel. An independent reference marker helps separate camera movement, but it does not solve every source of error.

These limitations shaped the product. Sometimes the most useful answer is a specific request for better evidence.

What I tested

All four bundled workflows passed on the public AWS deployment:

The synthetic baseline completed its analysis.
The stronger-motion recording triggered a comparison and an inspection work-order draft.
The tiny-marker recording requested a closer capture.
The ambiguous slow-motion recording requested reliable timing evidence.

For the two synthetic inputs with a known frequency of 24.3 Hz, VibraLens recovered 24.305 Hz and 24.301 Hz.

The final unit and API test suite passed 42 tests. The local approval test also verified that a decision could be accepted once and that a second attempt was rejected.

What I learned

A useful measurement tool needs to explain its limits as clearly as its results.

VibraLens has only been evaluated on synthetic recordings so far. I have not validated it on real machines or against an accelerometer. Absolute vibration severity and ISO zones therefore remain disabled; the current interface focuses on frequency and relative trends.

The next step is simultaneous phone and contact-sensor testing across different machines, speeds and recording conditions. I also want to improve processing time and make capture guidance easier to follow.

The prototype already demonstrates the workflow I wanted to build: inspect the evidence, measure what it supports, ask for what is missing, and keep maintenance decisions under human control.