Watching a system you spent months building confidently sort the wrong component into the wrong bin, and doing it fast, is a specific kind of humbling. That was my capstone, a YOLOv8-powered electronic component sorting system. It was one of the more educational things I've done as an engineering student, mostly because of everything that went sideways.
The Idea
On paper, the goal was simple: build a conveyor-based sorting system that could identify three types of electronic components, Axial Leaded, Radial Leaded, and DIP packages, and physically sort them in real time.
Anything the model wasn't confident about would fall into an "Other" bucket by default. I didn't train an explicit "Other" class, and honestly, that wasn't laziness. It was the only sensible call. What would an "Other" class even look like? You'd have to cover every random object that could end up on a conveyor belt: a screw, a coffee cup, a crumpled label, some random piece of debris. The list never ends, so the dataset you'd need to cover it never ends either. A confidence threshold does the same job without requiring an infinitely large training set. If the model isn't sure, it doesn't guess.
Simple enough, right?
Training: The Part That Felt Like Progress
I collected and labeled around 3,000 images. If you haven't done dataset work before, it's slow, tedious, and oddly philosophical. You end up staring at a resistor for 20 minutes asking yourself things like "is this angle different enough from the last one?" and "does background color actually matter here?"
Spoiler: it matters.
I wrote Python scripts to help with augmentation and semi-automate some of the labeling, which saved a decent amount of time. Still, 3,000 images is a grind when you're going through them manually. It sounds like a lot until you're on image 400 and realize you've barely started.
The strategy was static images with varied backgrounds to reduce overfitting. Give the model enough visual diversity and it should focus on the component shape rather than whatever happens to be behind it. By the numbers, it worked. The model hit around 99% precision on the validation set. Everything looked clean. I was pretty happy with it.
Then I plugged it into the actual system.
Deployment: The Real World Doesn't Care About Your Validation Set
85% real-world performance isn't a disaster. For a first-time physical deployment it's actually reasonable. But those missing 15% weren't random noise, they were consistent failures with specific causes.
Overlapping components were the biggest problem. On a real conveyor, parts don't always space themselves out neatly. Two components would drift together, partially overlap in frame, and the model would either miss one or get confused about what it was looking at. Almost all my training data was clean, isolated shots. The model had basically never seen two components touching each other. That gap showed up immediately.
Timing and latency caused a different kind of failure. The model would correctly identify a component, trigger the sorter, but by the time the actuator moved, the part had already passed. So a correct classification still ended up in the wrong bin. The AI made the right call. The system got it wrong. That's a frustrating distinction to debug.
There were also some purely mechanical headaches. At one point a motor kept stalling because of friction between a pulley and the conveyor wall. Not a model issue. Not a code issue. Just a piece of plastic rubbing against another piece of plastic. You spend weeks on hyperparameter tuning and then a conveyor component defeats you.
To deal with double-triggering (the sorter firing twice for one component), I put in a timer-based debounce. It works well enough, but a fixed timer doesn't adapt to changes in belt speed and occasionally creates its own timing problems. It's a "good enough for now" solution that I'd swap out for something sensor-driven if I built this again.
The Hardest Part Wasn't Training
Going in, I assumed the model would be where I struggled. The dataset, the architecture, the tuning, that's where I expected to spend most of my time fighting.
I was wrong. Integration was the hard part. It wasn't even close.
Getting a prediction out of the model is one problem. Getting that prediction to trigger the right physical actuator at the right moment, while a belt is moving, under inconsistent lighting, with components occasionally overlapping, that's a completely different problem. It's a systems problem. And I didn't really treat it like one until I was already deep in it.
What I'd Do Differently
A few things stand out in hindsight:
Start integration testing way earlier. I spent too long optimizing the model in isolation. A lot of the timing and latency issues would have surfaced much sooner if I'd been testing in the real environment from the start.
Collect data under real conveyor conditions. Static images are a reasonable starting point but they don't capture motion blur, part overlap, or the kind of inconsistent lighting you get from a physical setup. Even a small batch of footage from the actual conveyor would have helped.
Treat real-time constraints as a first-class design requirement. The timing architecture was basically an afterthought. It shouldn't have been.
Final Thoughts
The 99% training accuracy was real. The 85% deployment performance was also real. Neither number tells the full story on its own.
What the metrics don't show is the motor stalling, the pulley friction, the timer hacks, the parts overlapping at exactly the wrong moment, or the debugging sessions trying to figure out why a correctly identified component keeps ending up in the wrong bin. That's where most of the actual work lived.
If you're building something like this for the first time: take the integration phase seriously from day one. Test in the real environment early. And check that your pulleys aren't rubbing against anything before you start blaming the neural network.
It was a good project. I'd do it again, just differently.