COMPUTER VISION · OBJECT DETECTION
YOLOv11 Mango Detection
A documented computer-vision workflow that fine-tunes YOLOv11-n to locate mangoes in orchard images.
I structured the dataset setup, defined two training configurations, compared their recorded validation results, selected the tuned checkpoint and reported its performance on a held-out test split.
01 / PROBLEM
Detect fruit in visually complex orchard scenes.
Automated fruit detection can support later tasks such as counting, crop-load estimation and orchard monitoring. Before those applications are possible, the model must first localise fruit reliably despite leaves, branches, clustering, scale changes and uneven lighting.
The project question
Can a lightweight YOLOv11-n detector be fine-tuned to identify mangoes in the recorded orchard dataset and maintain useful performance on a separate held-out test split?
The scope was deliberately limited to one class—mango. The project does not infer ripeness, quality, disease, variety or commercial yield.
Occlusion
Leaves, branches and overlapping fruit can hide object boundaries and reduce localisation quality.
Scale variation
Mangoes appear at different sizes depending on their distance from the camera.
Lighting
Highlights, shadows and colour shifts can change the visual appearance of the same class.
Clustering
Closely grouped mangoes make it harder to separate individual detections accurately.
02 / DATASET
Public data, documented attribution and separate evaluation splits.
The project uses a publicly available YOLO-format dataset from Roboflow Universe under CC BY 4.0. The source and licence are documented in the repository.
annotated orchard images
Used to compare experiments and choose the final model before viewing final test performance.
Used for the final reported metrics after model selection.
The complete dataset and trained checkpoint are excluded; attribution, setup and download instructions are provided instead.
03 / PIPELINE
A workflow designed for repeatable experimentation.
The cleaned notebook provides separate code sections for dataset validation, experiment configuration, validation comparison, final evaluation and inference.
- Python 3.12
- YOLOv11-n
- Ultralytics
- PyTorch
- CUDA
- Google Colab
- Pandas
- OpenCV
04 / EXPERIMENTS
Model selection based on validation evidence.
Two experiments used the same YOLOv11-n architecture, image size, batch size, optimiser and random seed. The tuned configuration extended the training budget, reduced the initial learning rate and increased early-stopping patience.
| Experiment | Purpose | Epochs | Learning rate | Patience | Val mAP@0.5 | Val mAP@0.5:0.95 |
|---|---|---|---|---|---|---|
| Baseline | Reference run | 50 | 0.0010 | 15 | 0.988831 | 0.701359 |
| TunedSelected | Longer, lower-LR run | 100 planned stopped at 77 | 0.0008 | 20 | 0.990000 | 0.703000 |
The selected run stopped at epoch 77 after no further improvement within the configured patience window.
Both configurations used pretrained YOLOv11-n weights, AdamW and a fixed random seed of 42.
The tuned model was selected using the recorded validation comparison before final test performance was reported.
05 / RESULTS
Strong detection scores with room for tighter localisation.
The selected checkpoint was evaluated on 86 held-out images containing 694 annotated mango instances.
Most predicted mango boxes corresponded to annotated fruit.
The model recovered a high proportion of annotated mango instances.
Detection was very strong at the standard IoU 0.50 threshold.
Performance decreased when localisation was judged across stricter IoU thresholds.
The gap between mAP@0.5 and mAP@0.5:0.95 is consistent with the detector finding mangoes more reliably than it places consistently tight boxes around them. Recall was also higher than precision, indicating high coverage with some remaining false-positive risk.
06 / PREDICTIONS
Inspecting outputs beyond aggregate metrics.
Prediction examples provide a qualitative view of how the detector behaves in orchard scenes, including fruit at different scales and levels of occlusion.



07 / MY CONTRIBUTION
From experiment configuration to a documented computer-vision workflow.
I reorganised the academic work into a public repository with explicit dataset setup, training configurations, recorded metrics, evaluation code and inference tooling.
Dataset workflow
Configured the YOLO-format directory structure, added image-and-label count checks, generated a runtime dataset configuration and documented attribution.
Experiment configuration
Defined baseline and tuned settings with shared image size, batch size, optimiser and seed, then varied the training budget, learning rate and patience.
Model selection and evaluation
Documented the validation comparison, selected the tuned run and reported final performance on a separate held-out test split.
Reusable tooling and documentation
Cleaned the notebook, created a configurable command-line inference script, added a model card and documented dataset and model licensing.
08 / REPEATABLE WORKFLOW
Code and documentation another developer can inspect and run.
The repository provides environment setup, dataset attribution, checkpoint-download instructions, experiment configurations, evaluation code and inference tooling. The external dataset and trained checkpoint must be obtained separately before dataset-dependent cells can run.
Training and evaluation code
Dataset checks, experiment configuration, recorded validation comparison, held-out evaluation and inference steps.
View notebook ↗ Google ColabCloud notebook environment
Open the cleaned notebook in Colab, then connect the separately downloaded dataset and checkpoint using the documented paths.
Open in Colab ↗ InferenceConfigurable command-line script
Run detection against an image, video, supported URL or directory with configurable weights, confidence, IoU, image size and output path.
View script ↗ Model cardCheckpoint access and boundaries
Download instructions, final metrics, intended uses, out-of-scope applications, limitations and licensing.
View model card ↗09 / LIMITATIONS
What the results show—and what still needs validation.
The held-out split provides performance evidence for this dataset and recorded training run. External datasets and target-device benchmarks are still needed to measure behaviour across new orchards, seasons, cameras and deployment environments.
Limited orchard conditions
The dataset represents a restricted range of locations, capture conditions and visual environments.
One held-out test split
The model has not yet been validated against a separately collected external orchard dataset.
Detection only
The model does not classify ripeness, variety, damage, disease or fruit quality.
No device benchmark yet
Latency, memory use and throughput still need testing on target local or edge hardware.
CASE STUDY 02