5.9 KiB
Machine Vision PoC
Explore camera-based inspection of production processes using reproducible illumination and machine vision. Build a reviewable defect catalogue and a small operator interface as the foundation for later software development.
First use case: surface inspection of Carbofol sealing membrane. The requirements, hardware estimates and experiments below describe this initial use case; future materials and processes may require different capture configurations, models and acceptance criteria.
Status: documentation and source placeholder only. No capture service, trained model, benchmark, validated detection accuracy or deployed application exists in this repository. Hardware has not been selected or purchased as part of this task.
How it works
The illustrations below show alternative capture arrangements and a proposed operator interface. They are AI-generated concept illustrations, not installation drawings, real defect evidence or screenshots of implemented software. Geometry and defect appearance are illustrative and not to scale. Teal cones represent camera fields of view; amber rays represent illumination.
1. Complementary views of the same surface
Camera A observes the surface approximately perpendicular to the web; camera B adds an oblique view. Diffuse light reveals surface appearance, while grazing light can make raised features visible through highlights and shadows. Both views target the same inspection region. In experiments, switch lighting recipes separately when needed to distinguish their effects; the drawing shows the available sources together.
2. An alternative: inspect both surfaces
If both surfaces matter, place one camera and a suitable light on each side of an unobstructed span. Each camera inspects its own surface. This is an alternative to the complementary-view arrangement, not a requirement for four cameras. Mechanical clearance, coverage and triggering still need to be established.
3. Detect, highlight and review
The proposed interface displays the latest captures and highlights a suspected defect on the matching image. The operator confirms or rejects the suggestion; the catalogue retains the image evidence and review history. Optional generated descriptions arrive later and do not delay the alarm. The illustrated monitor shows the complementary-view scenario above; it does not demonstrate detection accuracy.
Initial use case: requirements from the discussion
| Constraint | Current scope |
|---|---|
| Material | Carbofol membrane; exact product and surface variant to confirm |
| Web speed | Maximum 4 m/min |
| Observed width | Approximately 30–50 cm; not necessarily the whole production width |
| Cameras | Two: complementary views of one surface, or one per surface; interpretation and geometry to confirm |
| Processing time | Less than 60 seconds from capture to evaluation; precise acceptance definition to agree |
| Interface | Continuously show the latest captures, highlight suspected defects and raise an alarm |
| Storage | Persist and catalogue defect evidence and human review |
| Description | Small image-capable language model desirable, optional |
| Software | Open-source preferred; dependencies and model licences to evaluate when selected |
Current architecture proposal
Two cameras + controlled illumination + trigger
|
Capture and preprocessing
|
Vision / anomaly detection worker
|
SQLite metadata + image filesystem
|
FastAPI + small browser interface
| |
Immediate alarm Human review/catalogue
|
Optional asynchronous VLM description
(updates the stored result and interface later)
Detection results, persistence and alarms must not wait for language generation. A VLM can interpret crops; a text-only LLM can only describe supplied features. Predictions remain suggestions until reviewed. The working candidate is an Orin Nano Super 8 GB, subject to image-quality, memory and throughput experiments. An existing computer can support the first acquisition experiments.
This is an experimental inspection assistant. Machine-stop control and production acceptance/rejection integration are outside the current scope.
Documentation
- Architecture: capture, illumination, inference, interface and failure handling.
- Hardware options: historical budgets and unresolved procurement choices.
- Data model: SQLite entities, image storage and review history.
- Roadmap: experiments, acceptance gates and open decisions.
- Discussion provenance: source and treatment of earlier claims.
Software home
src/machine_vision_poc/ reserves the Python package. Its README describes intended boundaries. No dependencies, runtime commands or API endpoints are claimed to work yet. Introduce packaging and pinned dependencies with the first executable vertical slice, starting with recorded images before camera integration.
Keep runtime images, databases, model weights, secrets and generated outputs out of Git. The future application should accept an explicit data root, preferably on SSD and outside the checkout. Git tracks code, configuration examples and documentation; it is not the defect database.
This repository is local. Remote hosting and a project licence remain to be selected by the owner.