Python · YOLO · OpenCV · Prototype

Is it open, or closed?
Let a camera decide.

DesktopQualityInspector watches a live camera feed and classifies a mechanical part's state in real time — built entirely on consumer hardware and free-tier cloud services, not an industrial vision system.

YOLO11 / YOLO26 10–15 FPS on CPU Free T4 GPU training No committed binaries
How it works

Five stages, one camera.

01

Data collection

Photos of the part in each state — from a webcam, or a phone repurposed as one via DroidCam.

02

Roboflow annotation

One bounding box per photo. Roboflow versions the dataset and can augment it — rotation, brightness, blur — to multiply a small set for free.

03

Colab training

A YOLO11n / YOLO26n checkpoint fine-tuned on a free T4 GPU. No local CUDA setup required.

04

best.pt weights

The trained model — small enough to run inference on a normal desktop CPU.

05

Live inference

Every frame gets a color-coded box and label: green for open, red for closed.

Known limitations

What this isn't, on purpose.

Documented characteristics of the current pipeline, not bugs waiting to be discovered.

—

Detection quality depends far more on training-data diversity — lighting, angle, background — than on raw photo count.

—

Inference runs on CPU by default. 10–15 FPS is fine for a desk-level demo, not for high-speed production-line throughput without a dedicated GPU or edge accelerator.

—

cv2.CAP_DSHOW is used explicitly for Windows; Linux or macOS requires adjusting the backend in open_camera().

—

The bundled example is one binary state pair. Multiple classes are supported by the underlying model but untested against this project's dataset.

—

Streaming over Wi-Fi via DroidCam adds latency and is more sensitive to network quality than a wired USB camera.

Why it's built this way

Four calls worth explaining.

01

DroidCam instead of a dedicated camera

A phone over Wi-Fi exercises the exact same cv2.VideoCapture code path real hardware would. Swapping in an industrial camera later is a --source value change, not a pipeline change.

02

A nano model, not a bigger one

live_inference.py targets a normal CPU, not a dedicated inference GPU. YOLO11n trades a little accuracy for the speed a live demo actually needs.

03

Dataset and weights stay out of git

Images and .pt files are large, regenerable binaries. The dataset lives on Roboflow; best.pt is one Colab run away.

04

Training happens on Colab, not locally

A free T4 GPU with zero local CUDA setup, in a notebook anyone cloning the repository can rerun against their own dataset.

Configuration

Every run, tunable from the command line.

--modelPath to the trained YOLO weights — default models/best.pt
--sourceCamera index, video file, or stream URL — default 0
--confMinimum confidence to draw a detection — default 0.5
--imgszInference resolution — lower is faster, less accurate — default 640
Class colors are configured once in config.py — lever_open renders green, lever_closed renders red, matching the labels used on Roboflow exactly.
Get started

Point it at your own two states.

01

Clone the repository

git clone https://github.com/mirconegri/DesktopQualityInspector.git
02

Set up the environment

python -m venv .venv, activate it, then pip install -r requirements.txt

03

Find your camera

python scripts/list_cameras.py — previews every index so you know which one is DroidCam.

04

Run live inference

python src/live_inference.py --model models/best.pt --source 1

Built in the open, tested on a lever.

Look at the code, train it on your own two states, or open an issue.

Multi-class supportEdge deployment (ONNX/TensorRT)Detection loggingWeb dashboardDocker image