UAV edge intelligence
Search-and-rescue drones film thousands of frames, and sending all of it to the ground is slow and drains the battery. I built a UAV that cuts its video down on board to the few frames with a person in, and keeps only those to send.
The problem
In a disaster, a drone's video is only useful once it reaches the team on the ground. Streaming all of it clogs a link that is often weak or missing, slows decisions and drains a battery that only lasts 20 to 30 minutes of flight.
What I did
I built the drone from off-the-shelf parts and wrote the software that runs on it. A Raspberry Pi on board drops frames that repeat, checks the rest for people, and rebuilds a short video from only the frames with someone in.
How it works
Film
A camera on the drone films the area being searched.
Drop the repeats
On board, any frame that looks almost the same as the one before is dropped. A 4,024-frame test video came down to 19.
Look for people
A small detection model checks the frames that are left and keeps only those with a person in.
Keep it short
A short video is rebuilt from just those frames, ready to send to the ground team. In testing, the sending was simulated.
On the UAV, Raspberry Pi 4
01Capture
A RunCam 5 Orange films while the UAV flies. A Raspberry Pi 4 Model B with 4 GB is the only computer on board for the pipeline.
- RunCam 5 Orange
- Raspberry Pi 4 Model B 4 GB
02Keyframes
Frames are downsampled and compared by histogram. A frame is kept only when it differs clearly from the last one kept. SSIM and MSE were tried and dropped: slower, and they kept frames that showed little change.
extract_keyframes()- OpenCV
- Python
03Detect people
YOLOv5n, 1.9 million parameters, checks each keyframe for the person class only. A frame without a person is dropped.
--classes 0- YOLOv5n
04Rebuild
The frames with a person in are written back into one compressed MP4.
rebuild_video()
Compressed MP4, simulated in testing
To the ground team
05Send
A script copies the video for sending and logs whether it worked. Sending over a radio link was simulated, not automated.
transmit_video()
In numbers
32.7MB
Output of the keyframe pipeline, against 906 MB for detection on every frame
19
Keyframes kept from a 4,024-frame test video
77%
Less energy than detection on every frame: 0.40 Wh against 1.75 Wh
Comparison model, 1.6 W per core
0.45%
Of an 88.8 Wh battery for one run, against 1.97%
Same comparison model
12.63min
To process the 4,024-frame test video on the Raspberry Pi 4, against 103.15 minutes for YOLOv5 on every frame
Paper p4 to p5. The final run also used the smaller YOLOv5n
1.9M
Parameters in YOLOv5n, chosen to fit the Raspberry Pi
My part
The UAV
I built it from off-the-shelf parts: frame, motors, flight controller, battery, camera and sensors.
All of it
Onboard pipeline
I wrote the keyframe filter, the person check and the video rebuild that run on the Raspberry Pi.
All of it
Research
I did all of it: the coding, the experiments, the analysis and the writing. I am first author, and colleagues at the university are co-authors.
All of it
Built with
- Raspberry Pi 4 Model B
- The onboard computer
- YOLOv5n
- Person detection
- OpenCV and Python
- Keyframes and the pipeline
- DeepSort
- Checking that no one was lost
- Pixhawk PX4
- Flight control
- RunCam 5 Orange
- The camera
In pictures
From the work
These are pictures of the project's own code running on simulated input. They show how it works, not what it found.
Where it stands
The paper won the Best Paper Award at IoT 2025 in Vienna, after I presented it.
What it found
The short video was 32.7 MB. Running detection on every frame of the same test video produced 906 MB.
By the paper's simple power model, the short route used about 77% less energy than checking every frame. The model compares the two methods; it does not measure the whole drone.
The people were still there. A tracker gave every person in the full video an ID, and the same people turned up in the 19 frames kept.
Histogram difference picked frames that reflected the video better than SSIM or MSE, and in less time, so the other two were dropped.
DeepSort assigned IDs to every person across all 4,024 frames, and the same IDs appeared in the 19-frame summary, so the filter kept the frames that mattered.
YOLOv5n was chosen over YOLOv8 and YOLOv11 for its mature deployment on ARM boards like the Raspberry Pi, not for its accuracy.
What went wrong
Close to too heavy
With the Raspberry Pi, camera, GPS and battery on board, the drone was near the most it could lift, so it flew a little less steadily and for less time.
The payload nears the UAV's lift limit, which slightly reduces stability and endurance; the Velcro battery mount also costs agility.
The computer ran hot
Under heavy work the Raspberry Pi reached 80°C and slowed itself down to cool off.
Sustained load takes the Pi 4 to 80°C, where thermal throttling lowers the frame rate.
The power model multiplies CPU use by a fixed 1.6 W per core. It compares the two pipelines under the same assumption; it is not a measurement of the whole system.
Transmission was simulated for testing. The pipeline was also started by hand, which a real mission cannot rely on.
What comes next
Start the pipeline on its own at take-off or over a marked area, send summaries to the ground for deeper analysis when there is bandwidth, and move to a more powerful onboard computer such as an NVIDIA Jetson.
A second phase is in discussion with the conference organisers.