Two detectors and an engine classifier, fused geometrically
A 61-page thesis and a working rig. Damage detection and part detection run independently, are matched by polygon overlap, and are combined with live engine telemetry into a single 0-10 health rating.
2024 — 2025 · for Final year project · ITU Lahore
84.3%
Damage mAP@50
42 ms/image, 120 epochs
87.6%
Parts mAP@50
38 ms/image, 23 classes
−50%
Inspection time
against manual process
14
Sprints
SCRUM, June 2025 submission
Pipeline
-
photos +
OBD-II -
damage
detector -
part
detector -
polygon
overlap -
weighted
score -
health
report
Two models instead of one
Damage alone is not actionable — a scratch on a bumper and a scratch on a windshield are not the same finding. A damage model over six classes and a part model over 23 run independently, then damage polygons are attributed to parts by overlap. The part model scores higher (87.6 against 84.3) because parts have stable geometry and damage does not.
A score you can argue with
Severity is weighted (scratch 1, dent 2, broken 3) and multiplied by part criticality (bumper 1, door 2, windshield and engine 3). Scores are summed, normalised against a worst case, and subtracted from ten. Every term is inspectable, which matters more than accuracy for something a mechanic has to defend to a customer.
The embedded half
An ESP32 reads the vehicle OBD-II bus over ELM327, structured as concurrent FreeRTOS tasks with queue-based inter-task communication and watchdog supervision. Six engine features — RPM, lube oil pressure and temperature, fuel pressure, coolant pressure and temperature — feed a Gradient Boosting classifier whose rating is the proportion of normal predictions across the sequence.
Validated on the physical rig
Host-side C unit tests cover the OBD-II frame parser, and the integrated system was validated through hardware-in-the-loop testing on the real rig rather than in simulation alone.
From the archive
“Overlapping instances are allowed — damage classes are not mutually exclusive in pixel space.”
Run log