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.pylever_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