Skip to content
Omotola
FR/EN
Special episode · ML · BMD-45 · Bengaluru · public dataset
← all projects

Vehicle detection

The cameras back home look at dense, messy traffic full of motorbikes, where distant vehicles are only a few pixels wide. Can a general-purpose detector still see them?

See the code on GitHub →

A Bengaluru street packed with motorbikes and cars, filmed from a CCTV camera. The generic model boxes only four vehicles, all in the foreground.
Before4 vehicles detected
The same Bengaluru street. The fine-tuned model boxes forty-four vehicles, down to the most distant and most overlapping motorbikes at the back.
After fine-tuning44 vehicles detected
Shipped

Acte I · The problem

1. e4 e5

YOLOv8 pre-trained on COCO recognises a car that fills the frame very well. But in a traffic-jam scene filmed from above, distant vehicles become tiny and overlap, and that is exactly where the general-purpose model falls apart.

The project’s question is precise: what does fine-tuning on dense-traffic data really change, properly measured, especially on small objects?

Acte II · The approach

2. Nf3 Nc6

First observation, owned from the start: there is no public computer-vision dataset specific to Benin. Rather than pretend otherwise, the project uses the public dataset closest to the problem: BMD-45, filmed by surveillance cameras in Bengaluru, India. The Beninese context is the motivation of the project, not the provenance of its data, and that transparency is part of the protocol.

  1. About 3,000 images extracted from BMD-45 (45,000 in total), with an isolated train / test split.
  2. 4 COCO-compatible classes: car, motorbike, bus, truck.
  3. YOLOv8n evaluated as is, then fine-tuned on this data.
  4. Comparison on the same test set, recall broken down by object size: small, medium, large.

rule of the game: everything is fixed before the first training run; what you fix beforehand protects you from what you’d like to tell yourself afterwards

Acte III · The results

3. Bc4 Bc5
Global metrics, pre-trained → fine-tuned
MetricBeforeAfterChange
mAP@0.50.4380.825+88.4%
mAP@0.5:0.950.2960.644+117.8%
Precision0.4960.833+67.9%
Recall0.4170.714+71.1%
F1 score0.4530.769+69.6%
Throughput (FPS)37.243.2+16.2%
Recall by vehicle size, before → after
  • Small (804)0.12 → 0.69 · +469.3 %
  • Medium (1,415)0.37 → 0.88 · +135.6 %
  • Large (332)0.79 → 0.95 · +20.1 %
The limits, stated plainly

These figures hold on the BMD-45 test set, not on Beninese roads, for lack of public local data. And inference on an ordinary CPU takes 1 to 2 seconds per image: enough for a demonstration, not for real time without dedicated hardware.

Acte IV · What I learned

4. O-O
  • Averages lie by omission

    The starting model’s global mAP didn’t say the essential: almost nine small vehicles out of ten missed. The breakdown by size is what put the real problem on the table. Since then, I don’t trust a metric before I’ve sliced it.

  • The protocol is played beforehand

    Like a chess opening: an isolated test set, metrics and comparison rules decided before the first training run. What you fix beforehand protects you from what you’d like to tell yourself afterwards.

  • Transparency is a methodological choice

    Writing in black and white that no Beninese dataset exists made the project stronger, not weaker: we know exactly what our figures prove, and what they don’t.

  • A recall of 0.12 is nothing to be ashamed of

    It’s the beginning of the story. The characters of my favourite stories grow by falling; a model progresses the same way, and so does the person training it.

documenting is thinking: every page written clarified a decision while there was still time to change it