Drone Lookout: Thermal Perimeter Surveillance Drone for Prescribed Burns
Advisor: Bhattacharya
Internship Location: Terra Fuego Resource Foundation
Onsite Mentor: Bill Jacks, Executive Director, Terra Fuego Resource Foundation
My project seeks to answer the question “Is it possible to develop a low-cost hexacopter with thermal vision and perimeter surveillance capabilities for applications in prescribed burning.” I believe this is possible, and the direction of my project will be building and experimenting with a self-assembled hexacopter platform. My final product should be a UAV prototype. It will reflect my effort in testing whether my research question can be answered. If I successfully build the UAV or see a clear path for others to follow, I will have a positive response to my research question. If I can't do this, I will provide a negative response to my research question.
Project Blog
Week 1: What's happened so far, and what does the future hold?
Intro:
Welcome to Week #1 of my blog! Here, I'll be detailing all aspects of my experience of completing this project. I will be sharing my grand plans, the ups and downs I face throughout the week, what I’ve learned, and what I plan to learn in the future. Let’s begin.
Background:
I currently have some domain expertise regarding this senior project, from my Synopsys Science Fair project from last year. In my science fair project, Measuring and Classifying Wildfires Using a Novel Drone-Based Approach, I designed a DJI F450-style drone kit, and mounted a custom assortment of hardware, including a Raspberry Pi and multiple cameras, to monitor fires and gather data to be used for threat assessment and resource allocation. Through this experience, I acquired the knowledge to design a custom drone build to solve a given problem. While I intend to use brand new parts for this project, I'll be borrowing some elements of my previous drone that I found optimal to work with. This includes the Pixhawk 2.4.8 flight controller for navigation, and the Raspberry Pi for edge-processing.
My science fair project also provided me the opportunity to gain non-technical expertise and knowledge. I visited a pile burn in Ben Lomond, which provided invaluable insight into what a real fire actually is. The sheer size and intensity of the fire was something that a youtube video simply couldn’t do justice to. I also met many prescribed burners who were extremely passionate about good fire and its benefits, including my external advisor Mr. Jacks, who encouraged me to pursue this project.
Progress:
The final part of this project that I have already completed was a flight mission/drone lookout simulator. I created it as my final project for my Advanced Java class. It served as a proof of concept for my project, and I will use it to run basic simulations of my flight missions, before I actually build my drone and take it on flights. The simulator uses the Dronekit-SITL library, which I am familiar with from my science fair project, as it uses the Dronekit library (Python), for navigation code. Dronekit is a simple library that interfaces well with PyMAVLink, a Python wrapper for the MAVLink communications protocol that many drones use, especially those using ArduCopter, the UAV version of the free autopilot software, ArduPilot. My project used a simple HSV-based color detection model to simulate the fire and smoke detection I aim to complete throughout my senior project.
Current Events:
Now that I’ve swiftly introduced my background, let me discuss the present and the future. Currently, my Raspberry Pi, Raspberry Pi 3 Camera, Raspberry Pi AI HAT+ Accelerator, FLIR Lepton 3.5 thermal sensor module, and PureThermal Mini Pro JST-SR thermal camera interface board have arrived. I will start creating an initial RGB smoke detection and plume tracking pipeline next week with these materials, and will implement thermal detection during Week 3.
This leads me to my first real problem of my senior project. I had originally planned my schedule around my Tarot 680 Pro drone frame arriving by Week 1. This would allow me to complete everything drone-related at the start. I would then move onto the Raspberry Pi and smoke detection work. I had a stable drone platform. However, I had a wrench thrown into my plans by shipping. My frame was slated to arrive by March 25, and I was left droneless for the time being. This led me to having to readjust my schedule and complete my Raspberry Pi and smoke detection work first, and put together my actual drone later. Though it was mildly annoying, I believe I’ve cleared this hurdle, and will continue developing the edge-components.
Next Steps:
The other point of contention on my project is the time of the actual burn. This is where I can actually test my platform. I’ve been told the burn should take place in April. But there is always a possibility it gets pushed up to late March, as weather is the key factor here. This means that I may have to adjust my building and testing schedule down the line. However, this issue is currently out of my control. I will instead focus on what I have right now, a fair bit of computational power and an assortment of camera modules, and I will push on for the time being.
Questions/Outro:
While I’ve provided a some information, I’d like to leave some questions to ponder until next week. Firstly, are there any experiences you’d recommend me to have or sources of knowledge you’d recommend I check out? Doing this during the early weeks of my project may provide me another perspective about my work? Secondly, is there any simulation software that may be particularly helpful for my project? I'd like to simulate the thin air conditions above a fire for me to simulate a drone’s flight in. And finally, are there any potential additions you believe I should make to my project? This can be either to improve its future capability to address its current goals, or provide new functionalities to increase its reach and potential applications?
Thank you for reading, and I hope to see you next week!
Key Terms:
OS: Operating System
UAV: Unmanned Aerial Vehicle
Week 2: Setup, Planning, and a Welcome Surprise
Intro:
Welcome to Week #2 of my blog! Last week, I spent a great deal of time planning for the remainder of the project and ordering parts online. Specifically, I ordered parts related to the detection and computing aspects of the project, as my drone frame wouldn’t arrive until late March. However, there’s been a surprising turn of events. By some form of magic, Amazon managed to deliver my drone frame on Wednesday, three weeks before it was expected to arrive. There are still some parts that need to be 3D printed, namely the forward camera tray, the downward camera tray, and upper deck shelf, but here's what the rest looks like (along with the sudden change of delivery date):
Figure 1. Drone components for the Tarot 680 Pro build laid out before assembly. Photograph by author, 2026.
Figure 2. Screenshot of Amazon order confirmation email showing expected delivery date. Screenshot by author from Gmail, 2026.
Figure 3. Amazon shopping cart containing components for the Tarot 680 Pro hexacopter build. Screenshot by author from Amazon, 2026.
The Present:
I’m currently at a crossroads about how to proceed. I had originally planned on completing the drone first, and then moved onto the Raspberry Pi. But with the frame being delayed, I pivoted to completing the Raspberry Pi work first. Now, I have the freedom to basically do one or the other, depending on how I feel. I also have the freedom to complete both at the same time. I can take a break from building the drone whenever I need to step away from hardware, and vice versa with the detection work. I’m likely going to perform the initial setup of both for now, and take the most optimal route from there.
I’ve flashed the right OS (operating system) on the Raspberry Pi, and can begin setting up its connection to my Mac. I’ve also begun creating the basic project structure in VS Code, as well as plotting out the system architecture, pictured in this mermaid diagram:
Figure 4. System architecture of the drone wildfire-detection pipeline generated from Mermaid code. Diagram by author, 2026.
Because the frame arrived, I had the chance to take some measurements and validate my initial drone design and components list before putting in any purchases. I found a critical issue: the of 15” propeller I wanted was actually too large for this frame. This meant that I could use a max of 13” props.
Next Steps:
Next week as the parts roll in, I plan to construct the initial frame with some basic wiring, as well as complete the initial smoke detection, which only uses the Raspberry Pi camera. The thermal detection with the FLIR Lepton 3.5 will be completed after that. I also plan to create data flow diagrams in Mermaid to represent both the Smoke Detection → Wind Estimation → Thermal Detection pipeline and the Autonomy Control Loop.
Questions:
Now for some questions for the readers. Do any of you know of anything similar or alternatives to Mermaid diagrams? I’ve found it to be incredibly helpful in putting my thoughts on (digital) paper and seeing how everything comes together. I’m wondering if there are any other tools like it that can provide a similar benefit to my workflow.
My other question would be: do you foresee any pitfalls in this project I haven’t covered? I think I’ve given a relatively comprehensive overview of this project and its goals via the project description and these past 2 weeks of blogs. I hope my readers are clear on these parts. However if there’s anything I need to clarify, please leave a comment and I’ll explain it all! Anyways, given your current understanding, are there any risky edge cases or unforeseen problems that my design doesn’t seem to cover, and I should factor in when purchasing parts for this build?
Final Treat:
And as a final treat, here's an AI generated image that will provide a rough idea of what I'm going for by the final build:
Figure 5. Concept render of the proposed drone system generated using AI (ChatGPT image generation), 2026.
Thanks for reading, and I hope to see you next week!
Key Terms:
VS Code: text editor used for programming
Autonomy Control Loop: Sense, decide, act cycle that continuously drives autonomous system behavior
Week 3: Parts and Planning
Intro:
Welcome to Week #3 of my blog! Last week, I mentioned that I’d work on both the drone and the Raspberry Pi simultaneously. Well while my drone frame had arrived early, the electronics did not. Because they will still arrive in late March, I’ve been prioritizing Raspberry Pi connectivity and development so far. However, this doesn’t mean that I’m completely ignoring the frame either. Let me explain a bit more:
Parts:
Firstly, it isn’t like every electronic I need is missing. I currently have with me a Pixhawk 6C flight controller, PM07 power module, 5V 9A step down regulator, and my ESCs. I did experience some issues acquiring these parts however. Certain carriers like DHL, charged an extra fee ($87 for the Pixhawk) and held onto my item until I paid, citing tariffs. This increase in cost luckily doesn’t derail my project. However, I’ll need to remain vigilant in tracking all the parts I’ve ordered from multiple companies to avoid delays.
Raspberry Pi:
On the Raspberry Pi side of things, I’ve set up a GitHub repository for this project. This will allow a smoother file transfer experience, as I’m working on both Mac and the Raspberry Pi. I’m SSHing into the Raspberry Pi to stay on Mac as much as possible, but some things need to be run locally on the Pi. This week, I’ll finish the initial smoke detection, and maybe do some of the basics with the thermal camera. The thermal camera has some software that I may or may not have to use. I’ll test its compatibility/usability on the Raspberry Pi as well.
Planning:
Last week, I mentioned wanting to create a few data flow diagrams to help me with the final code. I hope they also provide some insight to my readers about how I’ll go about doing this project. Here’s what I’ve created so far:
Figure 1. Diagram of the Data Flow (Smoke Detection → Wind Estimation → Thermal Scan) pipeline created using Mermaid. Diagram by author, 2026.
Figure 2. Diagram of the Autonomy Control Loop created using Mermaid. Diagram by author, 2026.
Figure 3. Diagram of the Autonomy State Machine created using Mermaid. Diagram by author, 2026.
Figure 4. Diagram of the Power Flow created using Mermaid. Diagram by author, 2026.
Questions:
For this week, I only have two questions. Have any of you experienced difficulty/barriers in obtaining items due to tariffs or similar reasons? I’m curious if this is a common phenomenon. Secondly, have any of your projects seen noticeable differences when using a Raspberry Pi 4 vs a Raspberry Pi 5? Though I highly doubt it, I may have to pivot to a Raspberry Pi 4, as it’s explicitly stated to be compatible with my thermal camera according to its manufacturer. Just keeping my options open.
Thanks for reading, and I hope to see you next week!
Key terms:
ESC: electronic speed controller which controls how a motor spins (speed, direction, etc.)
SSHing: logging into and controlling a computer from another computer
Week 4: Model Training
Intro:
Welcome to Week #4 of my blog! This week, I spent the majority of my time training the wind and fire detection model that I will eventually run on my Raspberry Pi 3 camera. This model I chose to use is the YOLOV8 nano, as I have experience using it from past projects and robotics. It also suits this use case well. If needed, I may use a YOLOV8 small instead after testing the nano. Let me now detail my experience training this model.
Kaggle
This was my first time sourcing datasets off of Kaggle for a personal project. For reference, I built my dataset by combining the D-Fire dataset (https://www.kaggle.com/datasets/sayedgamal99/smoke-fire-detection-yolo) and the FIgLib/HPWREN dataset (https://drive.google.com/drive/folders/1IKXN2-hxTrEQsIIKOxiUAuLgoxubA9Wq). I usually annotate data on Roboflow and download it from there, or hand-create datasets off of sources like Google Earth Engine (for satellite imagery). Kaggle was very convenient to use, and I look forward to using it in the future.
Issue 1: Slow Image Upload:
So now I'll detail some issues that I've faced so far when trying to train my model. I had initially uploaded my entire dataset (combining both D-Fire and FlgLib, so roughly 23,718 images and 31,945 labels) into Google Drive, which took roughly 7 hours. I then mounted the drive and have the notebook pull images and labels from there. However, this led to ludicrously long epochs (see below):
Figure 1. Screenshot of epoch training time. Image by author, 2026.
It was taking 1 hour an 10 minutes to complete 29% of the first epoch of 100. This was simply unacceptable. So, I looked for solutions online, and saw a recommendation. It was to mount my drive, and then move my entire dataset into the runtime's file system. The notebook would then pull files from there during training, instead of my Google drive. I wasn't expecting this to work, but surprisingly, it did. It now takes roughly 15 minutes to copy the dataset over, and roughly 7 minutes/epoch to train.
Issue 2: Sleepy Laptop and Disconnecty Runtime:
Another issue kept running into was that the runtime would disconnect everytime my laptop fell asleep, or the browser just felt like it. It was incredibly frustrating. To fix this, I added a feature where the model's current state is saved in a last.pt file after each epoch. When the runtime gets disconnected, I can input that last.pt file and have the notebook resume training from that checkpoint.
Updated Data Flow Diagram:
As I mentioned in a response to one of the comments on last week's blog, the Data Flow Diagram I included there was actually slightly outdated, as I had changed some of my methodology. Please find the updated Data Flow Diagram here:
Figure 2. Updated Diagram of the Data Flow (Smoke Detection → Wind Estimation → Thermal Scan) pipeline created using Mermaid. Diagram by author, 2026.
Questions:
The biggest question for me this week would be: does anyone know a way to keep a runtime using a GPU (T4 in my case) from disconnecting when the GPU isn't being used? What's happening is that whenever I start the runtime, I set it as a GPU-High RAM runtime. But when I do the initial step of uploading the training data from drive into the runtime's file system (before training), this process doesn't use the GPU, prompting Colab to automatically disconnect the runtime. The only current solution I've found is buying Colab Pro+, which is $49.99/month. If there is no other solution I'm ready to do this, but I'd like to try a bit first before I do so.
That's all for this week. Thanks for reading, and I hope to see you next week!
Week 5: Raspberry Pi Setup and the First Burn
Intro:
Welcome to Week 5 of my blog. Last week, I started training my model, but ran into some hiccups along the way. This week, I’ve finished the training, and have moved onto Raspberry Pi work. I also did some hardware work. Let’s get into it.
Model Training:
I ended up purchasing Colab Pro +, which gave me access to background execution, so my model would continue training even if my computer fell asleep, or the runtime got interrupted. However, it seems that I didn’t need it, as the model training resumed from Epoch 74 and wasn’t interrupted. I’m fine with this though, as I can still use the background execution and extra tokens if I ever need to retrain my model in the future.
Soldering:
I attended a soldering workshop at Maker Nexus. It was highly informative, and I definitely recommend it to anyone interested in learning it. In the workshop, I made this spinning top, which lit up after reaching a sufficient speed.
Figure 1. Top view of soldered spinning top. Photograph by author, 2026.
Figure 2. Bottom view of soldered spinning top. Photograph by author, 2026.
The day after, I tried to do some PCB prep on my drone frame’s PCB, which included leaving clumps of solder on the electrical connections, to make future soldering easier. However, this proved to be challenging, as my soldering iron’s tip became very dull, and I was unable to clean it with my brass sponge.
Figure 3. Dirty soldering iron. Photograph by author, 2026.
To fix this, I ordered some tip tinner which, while slightly acidic, would allow me to clean the tip and proceed with soldering. This would take a few days however, so I switched to Raspberry Pi work instead
Raspberry Pi Work:
I have two SD cards, an 8GB one for my Pixhawk flight controller and a 64GB one for my Raspberry Pi. A few weeks ago, I flashed my Raspberry Pi OS onto the 8GB card, requiring me to create a copy of the card on my Mac, and flash it onto the 64GB one. I was previously unaware this was possible. I might use this process to keep backups of my Raspberry Pi work after large milestones in the future.
With the SD card fiasco taken care of, my next step was to attach two accessories to my Raspberry Pi, a cooling fan and the AI Hat accelerator. I added both of them (see images below) and started camera work.
Figure 4. Raspberry Pi 5 with mounted fan. Photograph by author, 2026.
Figure 5. Raspberry Pi 5 with mounted fan and AI accelerator. Photograph by author, 2026.
Figure 6. Raspberry Pi 5 with mounted fan, AI accelerator, and connected cameras. Photograph by author, 2026.
Camera Work:
On the camera side of things, I made great progress, as I was able to test both cameras, and either take a picture or get a live video stream from both of them. Here are some results.
From the RGB-based camera I got a test image:
Figure 6. Raspberry Pi Camera Module 3 test image. Photograph by author, 2026.
And from the thermal camera, I got the following readings:
Figure 7. Thermal Camera test image picturing human. Photograph by author, 2026.
Figure 8. Thermal Camera test image picturing normal lighter. Photograph by author, 2026.
Figure 9. Thermal Camera test image picturing blowtorch-style lighter. Photograph by author, 2026.
Figure 10. Thermal Camera test image picturing soldering iron set at 400ºC. Photograph by author, 2026.
One interesting revelation from my tests come from the image above. As mentioned in the caption, I set the soldering iron to 400ºC (752ºF), however the camera is only reading it at 266.3ºF. While soldering, I felt that the iron wasn't as hot as it should have been, as I was having some difficulty heating some solder wire. When scanning with a laser thermometer, the reading was a little lower too. I may have to get a new soldering iron now, if this problem persists.
Burn:
My final piece of exciting news is that I will be visiting a burn this weekend! It will be in Nevada City, and I will be spending the weekend there. Many thanks to my external advisor Mr. Jacks and the Terra Fuego Resource Foundation for inviting me to be a part of this good work. Though my drone isn’t ready, I still plan to make the most of this opportunity. I’ll do this by flying a drone (Holystone HS360S) to gather some test footage and practice flying a drone in a burning area. I will also connect my Raspberry Pi to a battery pack, and gather footage using both the thermal camera and Raspberry Pi camera for future testing.
Questions:
I don't have many questions this week, as my next steps are pretty clear. I guess the only one would be: Has anyone ever used a Halio-based model/system, and were there any quirks while setting it up and inferencing it?
That's all for now. See you guys next week!
Week 6: First Burn and Next Steps
Intro
Welcome to Week 6 of my blog. At the end of last week’s blog, I made a brief mention of my trip to Nevada City. Well let me tell you, I am GLAD I went on this trip. It was incredibly informative, and has led to a major shift in direction for this project. Let’s get into it.
Day 1: Standing Dead Documentary and Expert Panel
The first big thing I saw on my trip was a screening of the Standing Dead documentary. It was a difficult, yet eye-opening experience, as it cemented in my mind the necessity of preventative measures against wildfire, like prescribed burning. In the face of a ring 100ft. tall burning trees, there’s only so much a fire engine can do. I highly encourage you to watch the documentary yourselves. It takes up less than 12 minutes of your time, but is highly informative and impactful.
After the screening of the documentary, I listened to an expert panel, which included my external advisor Mr. Jacks, answer some FAQs about how Nevada County residents can begin fireproofing their communities. A key data point I gathered from this was that some of the woodlands in California have 4x the number of trees they should have. This will be important later.
The panel was able to address another doubt I had about prescribed burning. Growing up, people all around me had been saying how deforestation is rampant, and that we need trees. Prescribed burning (specifically pile burning) felt rather counterintuitive. To this, the panel made an excellent point. In this part of California, frequent small fires were common, and sometimes encouraged by the land's earliest inhabitants (Native American tribes). These fires would burn some of the weaker saplings before they could grow into trees, but this would keep the soil healthy. However, due to the lack of fire over the past hundred years, the saplings that should have died via natural selection, have instead grown, becoming a risk and liability to both the environment and its current inhabitants. This made sense to me, and I was ready for burning the next day.
Figure 1. Standing Dead Documentary Viewing Expert Panel and audience. Photograph by author, 2026.
Day 2: Burning
I began day 2, ready to record some great footage with my camera drone and Raspberry Pi cameras. I joined Terra Fuego on their briefing, and afterwards, started setting up my drone and Raspberry Pi. So you can only imagine my frustration when my drone refused to connect to the receiver, and my thoroughly tested recording script threw an unknown error. After about 30 minutes of troubleshooting, I fixed the drone, and decided to shoot some footage:
Figure 2. Drone Flight 1. Footage by author, 2026.
Figure 3. Drone Flight 2. Footage by author, 2026.
Figure 4. Drone Flight 3. Footage by author, 2026.
As you all can hopefully tell from the footage, it’s virtually impossible to see the flames of the fires from the air. This footage was taken during a broadcast burn, where the flame height is usually < 4ft. However, I wasn’t expecting there to be not even a single pixel of flame. I believe this viewing difficulty stems from the fact that the canopy is 4x as thick as it should be. For a minute, I was a little bit worried about the future of this project. I discussed these findings with Mr. Jacks, and he explained to me that it was ok.
He stated how the only thing they really needed out of my drone, was a thermal camera in the sky, that could reliably be used to spot breaks in the fire line and hotspots, and record their GPS position. This would allow Terra Fuego’s team to respond ASAP, and put out the emergency. With this information, I decided disconnected the RGB camera from the Raspberry Pi, and tried to test the thermal one with a new script. As the smoke started to build up though (and started causing some coughing), I had to call it quits and leave. However, this was actually ok, because I had already got more than I needed from this trip.
The New Design:
Based on this, I’ve come up with some new specs. As they are simply no longer needed, I will drop the RGB camera and the Raspberry Pi AI accelerator, as well as the model I trained for inference. I will instead add a few telemetry modules to display both a thermal livestream, and an RunCam livestream for piloting. The drone will now no longer be a stationary lookout, but will instead be actively patrolling around the burn perimeter, searching for any emergencies. I will also have to add GIS (Global Information System) integration with Terra Fuego’s mapping system, but I don’t believe it will be too difficult. This trip has allowed me to drastically refine my project, and I’m very glad I got this experience. Here are some photos:
Figure 5: Broadcast Burn Image 1, Photograph by author, 2026.
Figure 6: Broadcast Burn Image 2, Photograph by author, 2026.
Figure 7: Broadcast Burn Image 3, Photograph by author, 2026.
Figure 8: Broadcast Burn Image 4, Photograph by author, 2026.
Hardware Updates:
So, I have good news and bad news. Let’s start with the good news.
The good news is, I was able to overcome a large roadblock in the drone frame construction process. The very first step was to put some solder on my integrated-PCB in order to prep it for future soldering. However, every time I tried to put solder down, the solder either wouldn’t stick to the board, or would make uneven clumps. I was puzzled on why this was happening, as I was doing everything right soldering-wise.
I thought it might have been my soldering iron, as if you all remember from last week, I suspected the soldering iron wasn’t becoming as hot as its digital display showed. But before that, I decided to try replacing the soldering wire with a more expensive one. And lo and behold, it worked. It was in fact, the cheap soldering wire that came with the iron that was screwing me over. Here’s the board for reference:
Figure 8: PCB Image, Photograph by author, 2026.
The messy patches at the bottom were done with the cheap wire, and the nice clumps on top (which I was expecting) were done with the quality one. My board is now ready for assembly!
The only bad news I have now is that my ESCs are the wrong ones. I ordered 60A escs, but received 80A ones instead. You might think that it’s fine, and that I can just run the 80A ones at 60A. But there’s a problem. The 60A ESCs are already a little big, and will be a tight fit in my design. But the 80A ESCs are massive. See below:
Figure 9: 80A ESC size reference, Photograph by author, 2026.
I’ve already ordered 60A ones to replace these, and put in a return request. They should come in in 2 weeks. Also, I’m missing a bracket that holds the middle arms of my hexacopter together. I’ve replaced it with a few M2.5 nuts in the meantime, but it’s not 100% safe to fly. Those will also take 2 weeks to arrive.
Here’s what the current build looks like too:
Figure 10: Tarot Frame Front, Photograph by author, 2026.
Figure 11: Tarot Frame Back, Photograph by author, 2026.
Questions:
So, I’ve decided to focus on the other aspects of the drone (motor mounts) and the Raspberry Pi work (thermal camera streaming and GIS location) instead. The only question I have for this week would be if anyone else has ever been to a prescribed burn? If so, please share your experience in the comments. That’s all for now, see you all next week!
Week 7: Delays and Good News
Intro:
Welcome to Week 7 of my blog. This week was a slower one. At the end of last week’s blog, I mentioned my two week delay due to the delivery of the wrong type of ESCs. I've got great updates regarding that. I've also got news on my latest weekly setback and how I solved it. Let's dive into it.
ESCs:
Amazon has done it again, delivering the ESCs two weeks ahead of time. I now have my 60A ESCs, and I just have to prep them. I'll do this by extending the wires and attaching bullet connectors on them, and the motors.
Electrical Stack Problems:
As I was reviewing my project, I came to the conclusion that key parts of my electrical subsystem were wrong. I've been using Claude over these past few weeks to verify my designs, and act as a second pair of eyes. Well this week, I wanted to order the telemetry modules. I would use to livestream my thermal and Runcam feeds from my drone back to the pilot. The wiring seemed to get unnecessarily complex, and in an attempt to get a grasp of things, I caught an error in my design.
My PM07 power module, which I distinctly remembered having two XT60 connectors for power, had only one. This was one of the most crucial points of my project, as it was responsible for converting 22.2V battery input to regulated 5.2V output for my electronics. At first, I thought it was a parts error, until I realized Claude had falsely told me it was compatible with my design. I quickly evaluated the rest of my design, and found a few similar errors.
Electrical Stack Solutions:
Luckily, as I had caught this relatively early in the week, I was able to spend the next few days brainstorming, and changing some of the orders for parts that I was about to place. Overall, I'd say the situation is now under control. I've ordered the right telemetry parts and verified they work with my newly modified electrical stack. I've verified this stack by manually checking the connections myself, and ensuring the inputs and outputs in my design actually match the physical product.
Questions:
I don't have any questions this week, as I'm pretty clear about my next steps. My original plan for this week was to prep the ESCs and motors, and start preparing for flight. But I got side tracked by this electrical system fiasco. I'm glad I've taken care of this now though, as if it happened two weeks later, the project might have been at risk. As I'm not out of the woods quite yet, I'll still push on at full speed. Next week, I'll start preparing the frame for flying, and 3D print a casing for all the mounted electronics on the drone.
Key terms:
ESC: electronic speed controller which controls how a motor spins (speed, direction, etc.)
PM07 Power Module: Converts 22.2V input to regulated 5.2V output
XT60 connector: certain standard of electrical connector
Week 8: Motor and ESC Prep
Intro:
Welcome to Week 8 of my blog. This was another slower work week, but I can say with confidence that great progress was made. Let's get into it.
Motor Prep:
I had to do a little bit of work on the motors before mounting them to the drone. The steps were to:
1. Cut the excess motor wire
2. Strip the ends
3. Solder the ends to male bullet connectors
4. Apply heat shrink to the joint to make it electrically safe
Here's the final product:
Figure 1. Prepped Brushless Motor. Photograph by author, 2026.
ESC Prep:
As a visual aid for this next section, here's a picture of my soldering workspace:
Figure 2. Workspace and removal of factory-soldered wires. Photograph by author, 2026.
My first task to prep my ESCs was extending the battery wires, as the factory-soldered wires are too short. The process was the following:
1. Cut heat-shrink tubing to expose soldering points
2. Remove factory-soldered wires
3. Cut new red and black 12AWG wire
4. Strip wire ends
5. Tin wires
6. Solder wires to ESC
Here's a picture of two ESCs. The top one is the original ESC, and the bottom one is one I modified. Please use this image as context for the above process:
Figure 3. Original and Modified ESCs. Photograph by author, 2026.
Next steps/Questions:
My immediate next steps would be to solder female bullet connectors to each of the ESCs (three wires on the left), so they can connect to the motors, and start wiring up the rest of the drone. I'll aim for it to be flight ready by Monday. My only question for this week is, does anyone know a good fan to use while soldering? In my experience, not matter what fan you use, the smoke always finds it way back to my nose. I can't use a large fan, as it'll blow all the flakes from the wires everywhere. But I want to avoid inhaling the flux fumes as much as possible. Please let me know if there's something worth getting. Thanks for reading, and I'll see you next week!
Week 9: Frame Construction and Wiring
Intro:
Welcome to Week 9 of my blog. I've got a lot of exciting updates this week, so let's get into it.
Flight Module Construction:
One of my first tasks this week was to combine the ESCs with the motor onto the motor mounts, and attach it to the arms. Here's an image of a completed product:
Figure 1. Completed Motor Mount . Photograph by author, 2026.
I knew beforehand that my 60A ESCs were much larger than the intended size 30A ESCs. So the standard mounting procedure wouldn't work for me. I was able to ziptie the ESC to the bottom of the mount, and fit the ESC's battery wires into the motor plate, so that they could go down the arm and reach the PDB (power distribution board).
As a side note, while the blue wires do appear loose, I will ziptie them to the motor mount in the final design. When I power on and test the motors, if I need to swap the motor direction, I'll switch two of the wire connections, meaning I should keep them loose for now.
Frame Assembly:
With the motor mounts assembled, my next step was to actually mount it to the arms. This was relatively simple, and just required me to route the ESC battery wires through the arms. Here's the final product:
Figure 2. Drone Frame. Photograph by author, 2026.
Wiring:
The next step was to wire the ESCs to the PDB. This was doable because I had cut the ESC battery wires to be extra long. I had originally cut them shorter. This required me to undo all my ESC soldering, and redo it with a longer wire.
Figure 3. Drone PDB Wired. Photograph by author, 2026.
Powering:
The final piece of work I've done so far is secure my PM07 Power Module. The wires in Figure 2 at the bottom of the PDB are connected to that. The power module is responsible for taking 22.2V from the battery, and splitting it between multiple outputs. This includes the ESCs and motors through the PDB, the Pixhawk 6C flight controller, and various BECs (Battery Eliminator Circuit). BECs essentially step down the voltage from the relatively high 22.2V to, for example, a lower 5.2V which the Raspberry Pi can use. Here's a top view of the PM07:
Figure 4. PM07 Power Module. Photograph by author, 2026.
With the PM07 wired in, I was free to use my multimeter and test the resistances and connections of all my wiring so far. And I am pleased to report that I did not detect a single overlap or issue that could lead to a short circuit or any other malfunction. This was a great boost in confidence for me, as it shows me that the work I've done so far is up to par, and I'm free to keep pushing.
Next Steps:
My immediate next steps are to wire in the remaining electronics to the PM07, which includes two BECs and a transmitter for my thermal feed. After that, I'll setup the flight controller, Raspberry Pi, and cameras and get a livestream going. I've only got one question for this week. Does anyone know if the mixture of the soldering wire can greatly impact performance? My mixture is 63% Sn and 37% Pb, which is typically used for eutectic electronics. The general purpose mixture is usually 60/40. Because my initial soldering wire was poor quality I ordered this without digging into the specifics. I'd just like to know if there's anything I should look out for when using this mixture. That's all for now. See you next week!
Week 10: Wiring and Camera Streams
Intro:
Welcome to Week 10 of my blog. With the initial drone frame completed, I was able to finish wiring and mounting most of my components, and verifying camera streams. Let's get into the finer details:
Transmitter:
There were many component I wired this week. One of them being the AKK X2-Ultimate Video Transmitter . This allowed me to stream my Raspberry Pi's desktop (which was running the thermal camera's livestream) to a radio-based external monitor.
Figure 1. Pre-modified AKK X2. Photograph by author, 2026.
For this, I had to cut off the JST-GH connector (the white one on the left of the screen), and strip, tin, and solder the wires to another pair of wires. I was initially nervous about this procedure, as if I messed up, I wouldn't have any second chances to reattach the connector. However, I was able to gather up my courage and do it. The operation was a success, and I now have a stable thermal video stream.
To automatically begin this video stream, I wrote a thermal_stream.py script that would open a preview of the thermal camera's feed on the Raspberry Pi's desktop. I then wrote a Shellscript script that would run the Python script 8 seconds after the Raspberry Pi is booted (when the drone battery is plugged in), and saved it as a service. This way, I shouldn't have to SSH or VNC into the Raspberry Pi myself to manually begin the thermal stream.
Here's a picture of the entire AKK X2:
Figure 2. Mounted AKK X2. Photograph by author, 2026.
Here's a picture of the working thermal video stream:
Figure 3. Thermal Video Stream. Photograph by author, 2026.
The Importance of Testing Connections:
An important part of this entire process that I may not have highlighted, is testing the electrical connections I've soldered throughout the entire build, testing for continuity and ensuring there are no shorts. I'd like to thank my internal advisor, Ms. Bhattacharya for telling me about this practice, which has given me confidence that about the quality of my build. Here's an image of my workstation that I took after testing some connections:
Figure 4. Workstation. Photograph by author, 2026.
The Build So Far:
Here's a picture of the build as it stands as of today:
Figure 4. Current Build. Photograph by author, 2026.
Additionally to the AKK, I've wired a RunCam (small camera at the front) to an HGLRC BEC (which steps down the voltage). This will provide a non-thermal video stream that the drone pilot can use when flying the drone. I've also mounted the Raspberry Pi and Pixhawk onto the upper plate/PDB. I've connected the Pixhawk to the PM07 power module (to power it), the M9N GPS, and SiK Telemetry module (which will stream flight data like GPS position to a ground laptop).
Here's a picture of both my drone's (my science fair drone and this project's drone) side by side to provide a size comparison. I feel like I've come a long way:
Figure 5. Hawk's Work F450 and Tarot 680 Pro. Photograph by author, 2026.
Next Steps:
My next steps are to wire the ESCs to the Pixhawk and test the motors, setup my transmitter and receiver that I'll use to pilot the drone, and mount propellors. I'll also have to meticulously test the various systems this build has under flight conditions. My only question for now would be: has anyone built and flown their own drone? If so, what was your experience? Please share in the comments below. That's all for now, I'll see you guys next week!
Week 11: Maintenance and Flight Prep
Intro:
Welcome to Week 11 of my blog. Last week, I mounted most of the electronics. This week, I did some more maintenance on it, and have began prepping the drone for flight. Let's get into it.
Maintenance:
As I mentioned in the comment section of my Week 10 blog, I accidentally caused a short circuit when in my system when testing voltage. This short blew one of my BECs. This BEC powered my Raspberry Pi and thermal camera stream stack. Luckily, nothing else was damaged. I've replaced this component, and ordered backups of all my other components.
My other piece maintenance work is to be done on the AKK Video Transmitter. While swapping the antenna for a better one, I accidentally snapped the antenna off, leading to part of it getting lodged into the AKK's port. After replacing it with the backup I ordered, I accidentally did the same thing again. I've ordered replacements, and the fix is easy. I'll be sure to be extra careful when installing the new one.
Flight Prep:
I started off by ordering the batteries for my transmitter/controller. The one's I initially ordered were too big to fit in the battery slots, so I had to order a second pair. Luckily, these batteries are rechargeable, meaning I don't have to constantly. I then calibrated the transmitter to work with these batteries, which required me to use a multimeter to measure the voltage.
I also started creating a flight profile on the transmitter for my Hexacopter. This will save the specific preferences for the my drone.
Finally, I finished soldering the receiver that connects to my transmitter to the drone. When I had originally tried doing so, I noticed that it wasn't getting the 5V it needed to turn on. This was how I actually discovered I had blown my BEC. But it's now up and running:
Figure 1. Transmitter and Receiver. Photograph by author, 2026.
Next Steps:
My next steps will be to finish the setup of my transmitter, test the motors, and fly. I don't have any questions for this week, as my next steps are pretty clear. See you all next week!
Week 12: Flight
Intro:
Welcome to Week 12 of my blog. This was the final week, and I'm proud to say that I made the most of it. I feel like I've completed weeks worth of work since last Saturday, but it was all worth it in the end. Let's get into it:
Transmitter and Receiver Work:
Original Transmitter and Receiver:
Last week, I tried setting up my RP3 Receiver and Radiomaster Pocket Transmitter. I thought that, given the ELRS communications protocol, I would have to wire it to the SBUS OUT port on my Pixhawk 6C:
Figure 1. SBUS OUT port on Pixhawk 6C. Photograph by author, 2026.
To do this, I cut off the end of one 3-pin JST-GH cable, stripped and tinned it, and then soldered it to the -, 5V, and T sockets on the RP3:
Figure 2. RP3 Receiver sockets. Photograph by author, 2026.
With this, the RP3 could at least be powered on and connected to the Pocketmaster controller.
However this week, when I tried to connect it to my laptop via Mission Planner, it couldn't locate the RP3. I then realized the SBUS OUT was an output port, and not an input one. So, I swapped it to the PPM/SBUS RC port, requiring me to redo the entire wire-prep process with a 4-pin JST-GH wire instead, and add a wire going to the R pad:
Figure 3. PPM/SBUS RC port on Pixhawk 6C. Photograph by author, 2026.
However, this didn't work either. After reading up online, I realized that since the RP3 outputs CRSF protocol it's T-pad, I would need to use a port that had a UART protocol to read it, which would be a telemetry port. So, I redid the entire wiring process with the TELEM2 port (refer to Figure 3 above). The final result looked like this:
Figure 4. RP3 soldered to 6-pin JST-GH cable. Photograph by author, 2026.
However, this didn't work either! At this point, I was rather done with the RP3 and Radiomaster. The Radiomaster Pocket itself was an extremely high quality and powerful transmitter, but I had no clue how to set it up. Online setup tutorials were lacking as well.
Final Transmitter and Receiver:
So in the interest of time, I decided to replace this setup with a FlySky FS-i6X transmitter and FlySky FS-iA6B receiver. I flew my previous drone with them, and I was familiar with the setup and calibration processes.
Figure 5. FlySky FS-i6X Transmitter. Photograph by author, 2026.
Figure 6. FlySky FS-iA6B Receiver. Photograph by author, 2026.
ESC Wiring:
With the transmitter and receiver work out of the way, I moved onto wiring in the ESCs to test the motors. On my old drone build, the pins that connect to the ESCs were a part of the flight controller (Pixhawk 2.4.8):
Figure 7. Pixhawk 2.4.8 ESC wiring. Photograph by author, 2026.
But the Pixhawk 6C was a different story. Instead of having these pins built in, the Pixhawk 6C has a PWM EXT board (external board), that I had to find space on the top plate to mount:
Figure Figure 8. Pixhawk 6C ESC wiring with PWM EXT board and ESC wire extenders. Photograph by author, 2026.
Because the board was on the left side of the drone, I needed ESC wire extenders to make the ESC wires reach. Since the connection was very loose. I put heat shrink on the connector, connected the two wires, and used a heat gun to cover the connection with the heat sink, providing it with stability (refer to black cover in Figure 8 with text "ReSuoG").
Maiden Flight:
With the ESCs wired, motors tested, and transmitter calibrated, it was time for my drone's maiden flight. As I set everything up at the park, I was quite nervous if the drone would even take off at all. It was designed for a lighter weight and smaller ESCs. There was a world where it couldn't get itself off the ground.
But I was confident in my math and parts selection. Given the time I spent research, building, and testing, everything should work. And I'm proud to say that it did. My drone had a smooth liftoff, and didnt struggle to carry its weight. This was huge. However, what happened next was less than ideal. For some odd reason, the drone started drifting to the right, without any translational input from my transmitter. Luckily I was able to ground it (with a bit of a crash landing). I tested this a few more times, and figured out that one of my propellors had been installed upside down. I fixed this and flew again, but to no avail. At this point, I had gathered enough data for now, and headed home
It turned out that two of the propellers had been chipped after the first crash. Thankfully, I had ordered spares 10 weeks ago, and was able to swap them out with ease. After examining the logs, it appeared that I needed to recalibrate my accel, to fix the rightward drift. I did this and headed out the next day
Attempt 2:
On my second day of flights, I saw some greater success. This time, the drone didn't just drift to the right! It instead drifted backwards, and a bit to the right. This meant that my fixes the day before had helped, but there was still something going on here. I was going to conduct a few more tests, but as I was lifting the crashed drone and preparing for another flight, one of the arms came loose. I think this is an aftereffect of the less than graceful landings. However, it "encouraged" me to look over my drone again, and ensure that every screw has been tightened.
There was another issue as well. My PM07 power module had a built in capacitor, that helped regulate the voltage the electronics (GPS, Pixhawk, etc.) received. Without it, the extra voltage may have interfered with the electronics' readings, compromising the flight. The capacitor comes pre-soldered to the PM07, but the connection was extremely thin and fragile, and in this last flight's crash landing, it broke. So, I had to fix it.
I intially struggled to do this, as the capacitor's legs were quite short, and quite far from the PM07's pads. I started by adding large amounts of solder to form pillars that I could attach the legs to. However, because the positive and negative pads were quite close, they often combined:
Figure 9. Combined positive and negative terminals. Photograph by author, 2026.
If I had plugged in the battery then, I would have shorted the entire board. I didn't do that of course. But I wouldn't be able to fly if it remained like this.
Figure 10. Separated positive and negative terminals. Photograph by author, 2026.
I separated the terminals with my soldering iron, and went for a different approach. I instead soldered 14AWG wires (20 or 22 would have been better but 14 is smallest I have), to the capacitor legs on one end, and to some free + and - terminals to the other end (and removed it from its covering to mount it in a safer place):
Figure 11. Reconnected Capacitor. Photograph by author, 2026.
Attempt 3:
During my first two attempts, I had been flying the drone in Stablize mode, which gave me direct control over the vertical acceleration with my sticks. However, after rewatching the flight tutorials I used in my science fair drone build, I realized that flying in Loiter mode might do the trick. Here's the result:
Figure 12. Successful Flight. Video by author, 2026.
As you can see, the drone flies! I am extremely happy that it worked, because it means that all of my research into the appropriate electronics, motors, ESCs, etc., was correct. It certifies that I know how to design a custom drone stack given specific mission parameters.
I was also able to record the RunCam and thermal camera streams during this flight:
Figure 13. RunCam Recording. Video by author, 2026.
Figure 14. Thermal Camera Recording. Video by author, 2026.
Conclusion:
I don't have any questions for my readers this week. The technical work is done. All that's left is to present it. Stay tuned for that, and see you next time!
Post 13: Presentation and Reflection
Intro:
This will be my final blog post. I've added a recording of my presentation as well as a copy of my slides below as well.
Presentation:
Here's the recording of my presentation. It serves as a thorough overview of my project from the top down. So, I highly recommend watching it:
Figure 1. Presentation Recording. Video by author, 2026.
Here are the slides I used as well for further reference:
Anav Senior Project Slides (1)-compressed
Reflection:
I am very pleased about the outcome of this project. The drone's design and assembly was successful, the thermal and RunCam streams worked well, and the laptop interfaced with Avenza and Mission Planner. I'm glad I did this project as I've learned a lot over the past 12 weeks. I've learned custom drone assembly, soldering, electronics and power system design, multimeter verification procedures, and iterative analysis through flight log debugging. I overcame the fear of irreversible failure, by gaining confidence to modify preassembled electronics to make them suit my build. And I learned about prescribed fire and its ecological importance.
I'm grateful to Ms. Bhattacharya for providing both technical and non-technical guidance to ensure the project ran smoothly, and for helping us make good pace on our work.
I'm also grateful to Mr. Jacks for his knowledge and expertise in prescribed fire, as well as providing me the opportunity to not only visit an expert panel on the subject, but also experience one myself.
I'm grateful to my parents, who not only helped me finance this project, but were also there for me when I needed help, be it strapping on batteries, driving me to the park for testing, or just discussing my results.
And finally, I'm grateful to you, the readers of my blog. No matter how many weeks you've been following along, you've also been a part of this journey, and I thank you for it. Blogging as a method of communication seems to be pretty useful, not only in communicating my work, but also keeping track of my steps and my progress. For future projects, I might consider blogging about it, and seeing how that goes.
That's all I've got for now. See you next time, whenever that might be!