Prometheus, an autonomous drone that will be under $600 and is purposed to fly autonomously through with help from my raspi through the MAVLINK protocol. The raspberry pi will also have computer vision to detect fires and report them to fire stations and optionally put them out with a CO2 bomb.
I’ve taken a break these past few days, realizing that a vacation exists for a reason! Today, however, I didn’t want to fall behind schedule. Since I also want grants to use a premium carbon fiber frame and all I need is to finish my PCB, I spent the day working in KiCad. Truth be told, the best way to learn is by doing—I thought the same about CAD, and I feel the same about PCB design. I made the executive decision to make a double-sided PCB rather than adding more layers, as it will be much simpler. Anyway, here are my final mockups.
I submitted my project, as is, to the Outpost fund, and I got some feedback. Mostly everything was good except for some issues with funding an NVDIA devkit :))), but the biggest issue was that I couldn’t buy a flight controller. In an devlog before, I mentioned and shows a picture of me designing a custom pcb, but I have not worked on that since. So today I fired up Kikad and designed layer 2 of my FC (easier, layer one has a lot of components that I need to import). I also spent a good chunk of today refining my 3d model, I used Air Shaper and SimScale and I aerodynamic tested all of the designs, I also asked claude for some ideas of how to make my .stls better. @vrunchil7 is da goat frfr he taught me how and what kikad is.
yea so while on vacation I decided to rework the weight and thrust ratios that the motors were producing with 11x7 props. I found out that my drone will not be able to fly SMOOTHLY. So I decided too look into why, one of the big reasons were that it was heavy, and two it wasn’t aerodynamic. So today I tried to kill two birds with one stone, (I also worked on my ML for a good portion of the time, but I feel this is more important). I ran digital wind tunnel tests and kept redesigning and testing until I landed on what I have now. I plan to make this out of carbon fiber which will be expensive, but ig that’s part of the process.
yea so training my own model wasnt the best idea.
after hours of clicking through my webscraper’s image results and marking them, i ran a benchmark myself by putting on youtube videos of wildfires from a sky perspective. it saw the smoke in the distance and gave that as the fire, when the real fire was miles away. it also found the sun and clouds as a fire. so, false positives everywhere.
so today i basically tested and worked with existing solutions instead, like this one: https://github.com/AlimTleuliyev/wildfire-detection, plus other open source alternatives on kaggle.
but yea, overall today i felt retrogressed, and i’m thinking of going back to CV. This article also helped a lot https://www.mdpi.com/2571-6255/7/4/140.
spent today on the data side of fire detection, which is half the battle with ML.
to train a model to recognize fire i need a solid labeled dataset, so first i built an image scraper. it crawls the web usinf breadth first search, going level by level through pages and pulling images as it goes. i used bidirectional bfs to expand the search from two fronts and cover more ground instead of just crawling one direction. ended up pulling a bunch of images, including a lot of tricky ones like trees and random orange stuff that a fire model could easily get confused by.
then i built a small labeling tool to actually tag all of it. it shows me one image at a time, a tree, an orange object, an actual fire, and i just mark it as fire or no fire. way faster than sorting through folders by hand, and getting those confusing orange non-fire images labeled is exactly what stops the model from false triggering later.
with some data labeled i started training a tensorflow model on it, mostly experimenting at this point to see how it behaves and what works. early days, but it’s a real step toward a model that actually learns what fire looks like instead of just matching colors.
good progress on the part of this project.
i genuinely lost my sanity working on ts
(Everything is on gh)
started on the payload for my autonomous quad: real time fire detection running on the Raspberry Pi.
went classical CV with OpenCV instead of training a model. Since it has to run fully offline on the drone (no internet up there) so a heavy ML model was out. turns out you get pretty far with just color + motion.
how it works:
the two bits that do the work. color mask first:
# warm/bright flame colors
warm = cv2.inRange(hsv, (0, sat_min, val_min), (35, 255, 255))
warm |= cv2.inRange(hsv, (170, sat_min, val_min), (179, 255, 255))
# fire skews R >= G >= B with a real red lead, not just any bright pixel
b, g, r = cv2.split(bgr.astype(np.int16))
order = ((r >= g) & (g >= b) & (r > 150) & ((r - b) > 28)).astype(np.uint8) * 255
warm = cv2.bitwise_and(warm, order)
then the flicker check. just how much the fire region changed since last frame:
diff = cv2.absdiff(mask, prev_mask)
flicker = np.count_nonzero(diff) / max(fire_area, 1)
# static orange object -> ~0 real flame -> way higher
built a web dashboard for it too (Flask). same code runs on my laptop off the webcam to test, then goes straight on the Pi headless and i open it from my laptop browser over wifi. console sits calm/cyan while scanning, goes full red + pulsing + beeping the sec it locks fire. got live sliders to tune sensitivity so i’m not editing code every time.
tested 4k fireplace video, locks on clean. waved random orange stuff
it’s not certified or anything. classical CV WILL false trigger in harsh light so
next: wire the “fire detected” event to grab the GPS coord off the flight controller and trigger a loiter so the drone marks the spot.
btw if anyone’s done fire/smoke detection on a Pi 4 lmk if you went CV or tflite, curious what fps you got. 🫡
ok!! so i went on a learning spree today and a LOT happened. ngl one of those days where you start the morning thinking you know stuff and end it realizing you knew nothing.
##i was doing my CV wrong
so my old fire detection was classical CV, just color matching + flicker. cool little hack and it technically worked, but tbh it was way too fragile. anything orange in bright light could set it off, and it’s is supposed to fly on a drone in the sun, so that’s not happening.
so i did the painful thing and scrapped the whole lot. felt bad deleting code that “worked” but it was never gonna be reliable enough out in the real world.
spent basically the whole day researching YOLO (you only look once, the object detection one). instead of me hand coding what fire “looks like” with color rules, the model actually learns it from examples. way more robust to lighting, angles, all the randome stuff a drone is gonna run into.
got a basic YOLO model up and running. its rough rn but its already a different league from the color matching.
also messed around with mediapipe today as a practice project, tracked my own body/pose in real time. wasnt strictly for the drone, just wanted to get comfortable with actual CV pipelines and see how the landmark tracking works under the hood.
im on vacation so no real flying, but i still wanted to test from a drone’s POV. so i straight up taped a webcam to my ceiling pointing straight down. now i can test the CV from that top down birds eye angle, which is way closer to what the drone actually sees than my laptop cam pointed at my face.
🫡
got through about half the CV code today, good progress on the rewrite.
right now i’m deciding between two routes for the actual fire recognition:
still weighing it. mobilenet-SSD is probably the stronger long term call since it generalizes better, but opencv is much lighter on the Pi, so i want to see what framerate i actually get before committing to either.
next: benchmark both and pick one.
not gonna lie, things went downhill pretty fast today.
i celebrated a bit early. all my motors spun fine on the individual motor test, so i figured i was basically there. then i hit “test all” and only 2 of the 4 motors spun. and it kept happening.
i was sure it was a software/parameter thing at first, so i spent hours over the past few days going through ardupilot params trying to get all 4 to fire at once. couldn’t get it. every motor spins perfectly on its own, but only 2 ever spin on the test all.
after sitting with it for a while, i’m pretty sure the issue comes down to the flight controller. i’d been running a cheap board that’s really built for fixed wing, and going through the ardupilot docs it just wasn’t the right fit for what i’m doing. so i’ve ordered a proper flight controller to swap in.
the timing isn’t great. i leave for my trip the day after tomorrow, so for the next month i’m stuck on just the software side, no hardware. the new FC is on its way but realistically i can’t promise the drone actually flies until the end of july.
bit of a setback, but at least i’ve got a direction now. onwards.
really good, productive session today. spent the whole day learning.
first half went into the machine learning side. since i want the algorithm to actually find and report fires properly, i went down a full rabbit hole on how AI works under the hood, neural networks, all of it. wanted to actually understand what’s going on instead of just copy pasting a model i don’t really get.
second half i switched gears to hardware and started designing a PCB. right now my gps/compass, the SBC, and the ESC are all separate boards basically taped to a surface, which is messy and not great for an actual flying build. the plan is to get all of them onto one clean board instead.
good mix of software and hardware today, feels like things are starting to come together.
oh my gosh. amazing and relieving day today.
i’d been pretty down about this for a while. my motors just wouldn’t spin during the bench test, and i’d already ordered three ESCs, new motors, and new wires trying to fix it. none of it worked, so i returned all of it. today my new ESC finally showed up. i leave for india on sunday for a month, so these next few days are my only window to get any hardware done.
so i sat down and meticulously (and painfully) soldered every joint, checking continuity with my multimeter over and over. a few connections literally fell apart while i was hooking up the wires, so i had to stop and resolder them. just wanted the wiring to be perfect this time.
then the worst moment: i tested it and nothing worked. again. i was genuinely gutted.
but then i noticed an orange cable just sitting there, not plugged in, and it clicked, that was the ground (GND). i connected the ESC ground to the FC ground, ran the motor test, and everything spun. all of it. no errors except some OSD stuff, which is just a missing SD card.
massive relief. that one unplugged ground wire was the whole thing.
next month in india i’ll be working on the code side of the drone, then test for flight again when i get back.
wow, rough day.
got my new ESC in and resoldered every connection as cleanly as i could. but somehow it went the wrong way, instead of just one motor not working, now none of them work. so that’s fun.
i’ve ordered another one. before i jump to blaming the flight controller this time, i want to go back through the wiring really meticulously and rule that out first. feels like it’s something small i keep missing.
annoying timing too. i’m away from the 20th to the 20th, basically a month, so i’ll be forced to work on just the software side until i’m back.
wish me luck pls.
today was a sad one.
my new wires finally came and i swapped them all in, but the one motor still wouldn’t work. after that i’ve basically narrowed it down to a board problem. either i damaged the FC with my rough soldering, or it had some issue before i even started.
so i’ve ordered a new board. i’m going on vacation soon, and i can only hope it arrives before i leave. if it doesn’t, i’ll be left to just improve, fine tune, and perfect the ML and software side until i’m back.
not the day i wanted, but at least i think i know where the problem is now.
tested the drone with the battery again and the one motor still wouldn’t spin.
while i was at it i calibrated most of the sensors, the accelerometer, GPS, and compass, so at least that side is sorted now. then i swapped the motor out again just to rule it out, and it still didn’t work.
at this point i’m fairly sure it’s either an ESC problem or a wiring issue. my new wires come tomorrow, so i’ll be able to narrow it down properly and do what i can to fix it.
slow progress, but i’m closing in on it.
plugged in the battery and ran a test today, found a few bugs.
the main one: one of the motors still wouldn’t work. so i went through it properly this time. resoldered all the connections, swapped in a known-working motor, still no spin. then i uncapped the battery pull going to that motor to check if it was a power issue, and still nothing. resoldered everything one more time, and it still wouldn’t spin.
at that point i figured it has to be the bullet plug connectors, so i’ve ordered new ones.
on the software side i actually made some progress, wrote some of the python autonomous flight code by SSHing into the raspberry pi. nice to move the code forward while the hardware’s still being stubborn.
big hardware milestone today, i designed and 3d printed the entire drone chassis.
did the whole design in onshape. spent a good while on the layout because the chassis has to hold everything: the flight controller, the ESC, the motor arms, the battery, the raspberry pi, and the gps/compass. i measured each component so i could put proper mounting holes and slots for all of them instead of just taping stuff to a plate. the motor arm spacing and overall geometry took the most back and forth, it has to be symmetric and square or the drone won’t fly right. M
after a few tweaks to the model i sent it to the printer.
next up is mounting everything onto it and starting the wiring.
Designed and assembled the legs for my drone. I also soldered some electronic connections to the ESC (Electronic Speed Controller).
kicking off a new project, an autonomous fire detecting and firefighting drone. the goal is a drone that can find and report fires on its own. starting with the hardware, so today i designed and printed the arms.
did the design in onshape. the arms are carbon fiber tubes for the length and stiffness, paired with 3d printed plastic attachments that clamp onto the tubes and hold the motors out at the ends. carbon fiber keeps them light and rigid, which is exactly what you want for the arms, and the printed parts let me make mounts that actually fit my motors and bolt onto the frame.
this session was mostly the build and assembly side, getting the carbon fiber pieces and the plastic attachments fitted together. feels good to have the first structural parts of the drone done.
solid start, the skeleton’s starting to take shape.
