← All workProject
Edge UAV for real-time pothole detection
A quadcopter that spots a pothole on its own, stops over it, and sends the photo, GPS position and a risk level to a web map.
- Period
- Sep 2025 – Feb 2026
- Role
- Team of five · drone platform and camera input
- Tools
- Jetson Orin Nano · Pixhawk · MAVLink · YOLOv8 · TensorRT · OpenCV · Flask · Python
- Status
- Done
- Result
- A quadcopter that spots a pothole on its own, stops over it, and sends the photo, GPS position and a risk level to a web map.
Road crews find potholes by patrol and by complaint. We wanted to see how far a small drone could go on its own: fly a route, recognise a pothole from the air, stop, record where it is, and report it, without streaming video to the ground.
This was a five-person industry-academia project (Daegu RISE PBL) in the School of Electronics Engineering at Kyungpook National University. I was responsible for the drone side: getting the aircraft flying and getting a clean camera image into the detector.
How it works
The aircraft is an F450 frame with a Pixhawk flight controller. A Jetson Orin Nano rides on top as a companion computer with a downward-facing Raspberry Pi camera.
- The Pixhawk flies the waypoint mission and handles stabilisation and GPS.
- The Jetson runs a YOLOv8 model, converted to a TensorRT engine, on the camera feed.
- When a pothole is detected during an AUTO mission, the Jetson sends a MAVLink command that switches the Pixhawk to BRAKE. The drone holds position, the Jetson asks for the GPS fix, and after a set hold time the mission resumes.
- Each detection becomes one small event: a JPEG, latitude, longitude, altitude, a risk level (high, mid, low) and a timestamp. Only that event is uploaded, not the video.
A cooldown timer and a GPS radius check stop the same pothole from being reported twice.
My part: the aircraft and the image input
A detector is only as good as the frames it gets, so most of my work was about what happens before inference.
In the first stage we used a DJI Tello to prove the loop end to end: receive the video stream, run detection, and have the result change what the drone does. I worked on receiving and decoding the stream with OpenCV and keeping latency down by always processing the newest frame instead of letting frames queue up. The stream first came out with a blue cast because of a colour-channel mismatch, which we corrected.
The Tello could not carry a computer or give us GPS, so the second stage moved to the Pixhawk F450. Here I worked on assembling and calibrating the aircraft in Mission Planner and on mounting the camera. A forward-facing camera distorts the size of anything on the ground, so the camera points straight down on a printed mount. To avoid a second battery, the Jetson is powered from the main flight battery through a step-down converter, which keeps the weight and the centre of gravity under control.
The detection model
The model went through three rounds, led by my teammates.
| Round | Data | Result |
|---|---|---|
| 1 | 2,469 public images, unchecked | mAP 0.641, enough to test the pipeline |
| 2 | 4,846 images after manual relabelling | mAP 0.898 |
| 3 | 5,396 images, including 550 negatives | fewer false alarms |
The negatives were manhole covers, hard shadows and clean road, the three things the model kept mistaking for potholes.
We started with a Raspberry Pi 5 and a Hailo-8L accelerator. Quantising the model for it dropped detection confidence too far to trust as a flight trigger, so we switched to the Jetson and TensorRT with FP16.
What I took from it
The plan changed twice, from Tello to Pixhawk and from Hailo to Jetson, and both times the reason was something we only saw once hardware was on the bench. A propeller mounted in the wrong direction kept the aircraft on the ground until we made a pre-flight checklist. Small things like that took more time than the code.
The work was written up as a paper, “Design of Real-Time Pothole Detection and Automated Control System for UAVs Based on Edge Computing and MAVLink,” submitted to JCCI 2026.