A pretrained detector has never seen your parts
An off-the-shelf detector knows generic public classes. It has not seen the specific components, board layouts, lighting, or camera angles of one particular line. So a team labels its own images and fine-tunes — and then owes itself a straight answer before anything else happens: did that training converge, and how good is the checkpoint it produced?
This run answers exactly that, and nothing more. It is deliberately narrower than a model comparison or a deployment benchmark, because a candidate that has not converged is not worth comparing or deploying.
The pool is imperfect on purpose
The training material is the public PCB Component Detection dataset — real photographs of printed circuit boards, originally assembled for electronics recycling, where a system has to spot which components sit on a board before it is sorted or stripped for reclaimed parts.
Nine classes span several capacitor grades, a MOSFET, a varistor, resistors, and transformers, at
very different physical scales: a small resistor and a transformer that dominates the board are the
same detection problem here. The mix is uneven, and the source labeling carries a wrinkle worth
naming — a stray duplicate class, Resestor alongside Resistor. Neither is cleaned up before
training, because that untidiness is what a real line produces.
The dataset ships with its own train/validation partitioning, so this run selects each portion by its split tag rather than inventing a fresh split: 1,099 labeled images for training, 200 held back for validation.
| Setting | Value |
|---|---|
| Model | EdgeCrafter ecdet_s, pretrained initialization |
| Parameters | 9,770,269 |
| Input resolution | 640×640px |
| Epochs | 21 |
| Batch size | 8 |
| Optimizer | AdamW, lr 0.0005, weight decay 0.0001, 2,000 warmup iterations, mixed precision |
| Training duration | 21m 4s |
The curve shows where training stopped paying
Validation mAP, AP50, and AP75 are measured after every epoch on the same 200 images. The shape of those three curves is more informative than the final number.
| Epoch | mAP | AP50 | AP75 |
|---|---|---|---|
| 1 | 1.1% | 2.0% | 1.1% |
| 3 | 59.9% | 85.2% | 72.1% |
| 5 | 65.7% | 86.8% | 79.2% |
| 14 | 67.2% | 87.6% | 82.5% |
| 20 (best) | 68.1% | 87.0% | 83.2% |
| 21 (last) | 66.8% | 87.1% | 82.7% |
Three readings matter.
The coarse question is solved in three epochs. AP50 — did the model put a box roughly in the right place — reaches 85.2% by epoch 3 and then never leaves a one-point band between 86.3% and 87.6% for the remaining eighteen epochs. Whatever the last two thirds of the schedule bought, it was not “finding the components.”
What kept improving was box tightness. AP75 climbs from 72.1% at epoch 3 to 83.2% at epoch 20, and overall mAP — averaged over IoU thresholds from 0.50 to 0.95 — follows it. That gap between a lenient and a strict threshold is the signature of a model still refining edges after detection itself is basically settled.
The plateau is noisy, not flat. From epoch 12 onward mAP swings between 59.7% and 68.1% epoch to epoch. On a pool this imbalanced that is expected: the remaining movement comes from the sparse, hard classes, where a handful of objects shifts the average. It is also a warning against reading any single epoch as the model’s true quality — including the last one.
The best checkpoint is not the last checkpoint
Epoch 20 scores 68.1% mAP. Epoch 21 scores 66.8% — 1.3 points lower. A pipeline that simply keeps whatever the training loop finished with would have shipped the weaker model and reported the weaker number, with nothing in the log to suggest a better checkpoint had existed five minutes earlier.
OvalBee keeps the best-scoring epoch as the delivered checkpoint and registers it as an addressable
model tied to this run, this dataset, and this configuration — rather than a best.pth on whichever
machine happened to run the job.
What the detector actually draws
Aggregate scores decide whether training worked. Predictions decide whether a reviewer believes it. These two boards come from the best checkpoint’s own predictions on validation images. Each colored box is one detected component, colored by predicted class; the exports carry no text labels.
Two examples are for review, not for scoring — the number comes from all 200 images. What they add is the kind of detail an average hides: which components attract tight boxes, and where crowding makes neighbouring parts compete for the same region.
What this number is, and what it is not
68.1% mAP is a training-time validation score, measured on the partition the training loop used to pick its best epoch. It is not an independent evaluation on an untouched test set, and the two are not interchangeable — the checkpoint was selected using these exact images.
This run also does not produce per-class average precision, so nothing here says how the detector
handles the rare classes specifically. Given the imbalance and the duplicate Resestor label, that
breakdown is the natural next question, not something to infer from an overall average. Latency,
memory, and cost are likewise unmeasured.
What it sets up
Training converged cleanly on this domain’s own images: from near zero to 59.9% mAP in three epochs, a best of 68.1% at epoch 20, and a curve that settles into a noisy plateau rather than stalling or reversing. That is the necessary first answer.
Because the import, the split selection, the export, and the fine-tuning all ran as one reproducible sequence, the checkpoint and the number describing it come from the same process — not a local training script with a score pasted in from a separate log. The registered model is the same candidate a comparison run weighs against a baseline, or a deployment step picks up, with no manual handoff in between.