InspekTron

The Problem

In many small and medium-sized textile manufacturing units, fabric inspection is still performed manually. Operators visually monitor the woven fabric for defects, making the process dependent on human attention and prone to missed defects.

The bigger problem is timing. A defect may only be noticed after the fabric has already been woven. At that point, the material has already passed through the production process, and the defect cannot be undone.

For MSMEs, this means wasted material, additional inspection effort, and potentially an entire length of fabric being affected before the problem is identified.

InspeKtron is built around one simple idea

catch the defect while the fabric is being made—not after it’s woven.

“Why retrofit?”

High investment costidentified as the biggest barrier to technology adoption.

So, WTF is InspeKtron?

Watch the fabric → Find something unusual → Check it with AI → Flag the defect

A camera observes the fabric. The system looks for regions that appear unusual, and an AI model checks whether those regions actually contain a defect- all retrofitted around an existing powerloom..

The important part is that the inspection happens locally on the edge device. There is no requirement to send the inspection workload to a cloud service or external inference server.

A small but important detail

Fabric inspection has an annoying enemy: lint.

Lint can look suspicious enough to trigger an inspection, even though it is not necessarily a production defect. In a factory, repeatedly stopping or flagging a production line because of harmless lint would make an inspection system almost as problematic as missing defects.

So the system is designed to be particularly conservative around lint and other visually similar patterns. The AI model was trained to distinguish actual defects such as cuts, holes and oil contamination from normal fabric and lint.

On the evaluation set, the model got 99.3% of classifications right and caught 99.5% of the actual defects.

What happens in practice?

The UNO Q runs the complete inspection locally:

Camera↓Fabric inspection↓Candidate regions identified↓AI classification↓Defect detected?↓Physical response

No cloud inference. No external AI API. No remote processing required for the inspection itself.

Quick Start

Getting InspeKtron running is intentionally simple:

git clone https://github.com/vamp-carti/Textile-defect-detection.git
cd Textile-defect-detection
./run.sh

cp -r firmware/videoledbridge ~/ArduinoApps/

Once the pipeline is running:

Open applab, run videoledbridge.

• Scan the QR code to connect the camera and start image ingestion.
• Open the local dashboard at port 8081.
• Let InspeKtron run its automatic calibration.
• Use the dashboard to start, monitor, and control the inspection pipeline.

And does it actually keep running?

The system was stress-tested across 1, 000 consecutive frames

During the test:

• No memory leaks were observed.
• CPU and GPU temperatures remained below 60°C.
• The pipeline sustained roughly 2 FPS on the UNO Q.
• Defects were flagged in under 800 ms
• The complete inspection pipeline ran locally on the UNO Q without an external inference dependency.

So InspeKtron isn't just a model that can classify a fabric image.

It is a multithreaded, asynchronous, CPU/GPU-accelerated edge inspection pipeline that manages image acquisition, candidate detection, ROI processing, inference, and physical response — all while running locally on the UNO Q.

And it doesn't just observe, decide, and respond.

It does all three continuously, concurrently, and on-device.

For the people who want to see how the sausage is actually made, the real nerdy stuff is on GitHub.

If You Can't Eliminate It --Reduce It. If You Can't Reduce It --Hide It.

Inspektron's first working version took roughly 10 seconds per frame.

So westarted optimizing. Partly out of necessity, partly for the love of the game.

Reduce the Work

We cut unnecessary I/O, reused buffers, kept ROI processing dynamic, and only sent relevant regions to inference. CPU and GPU workloads were also split according to what each could handle best.

Hide What Remains

Some work can't be eliminated — I/O is one example.

Instead of letting it block inspection, we moved the pipeline to an asynchronous producer–consumer architecture, allowing processing and file I/O to overlap.

Maybe add another thread, and run inference in parallel as well.

The work still happens. It just doesn't make the inspection wait.

The Result

~10 s/frame → <800 ms/frame

Making the Most of the UNO Q

InspeKtron doesn't throw everything at the AI model.

Each part of the UNO Q is used for what it is good at.

CPU: runs the algorithmic inspection and preprocessing.CPU + GPU: handle AI inference, with work distributed according to the workload.MCU: receives the final decision and drives the physical LED response.

So the inspection doesn't just run on the UNO Q — it actually uses the UNO Q.

The Linux side observes and decides.The MCU turns that decision into a physical response.

CPU → GPU → MCU

Three compute domains, one inspection pipeline.

Where This Goes Next

InspeKtron was built around making existing textile machinery smarter, cheaper, easierto integrate and easierto scale.

• CSV export: Inspection results can be exported directly as CSV, giving operators a simple record of the inspection run.
• Automatic calibration: The current system already handles calibration automatically, reducing setup before an inspection run.
• Simple physical feedback: The LED matrix can act as a straightforward factory-facing alert, so a worker doesn't need to constantly monitor the dashboard.
• Easy integration around existing machines: The core inspection pipeline can sit alongside the machine while the mounting, model, calibration, alerts, and data output are adapted to the specific production setup.
• Fabric-specific models: Different fabrics can have different visual characteristics and defect patterns. A future version could allow the system to switch between fabric-specific models or inspection profiles, making the inspection more robust across different production runs.

The idea is simple: keep the existing machine, and add intelligence around it.

This project is a prototype, not a claim of production deployment. The next challenge is taking what works on the bench and proving it under the noise, speed, lighting, vibration, and variability of an actual factory floor.

And that's where InspeKtron turns into a product!