Devlog #18: A GREAT way to start working on your project again 😩

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.

Devlog #18: A GREAT way to start working on your project again 😩

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.

Devlog #17: I tested a lot tdy as well as designed new components

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.

Today I went back and forth, since it is pretty late for me right now ill just give a quick overview. I went back on using sensors for hand movement as I felt that wasn’t practical. So I opted for a CV method. So i built this simple pinch tool today and designed a turret with two cameras in onshape. For cursor and key movement.

Devlog #17: I tested a lot tdy as well as designed new components

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.

Eclipse Lamp Devlog #9 - Posting all the CAD models on my Github and spicing up my ReadMe.

Today I probably worked more on my Github than I ever had before. I also learnt some cool new helpful stuff since I’m pretty much a noob to Github. Today I found out that if i press the period button on my computer it will take me to VS code on my computer or the dev version. With this I was able to minimize my commits by a lot and it was really cool to use it for the first time. Later I realized I had to add markdown files for my iris to camera frame CAD and my Iris Face Extension CAD models. While I was doing this I updated my Custom Created CAD models file. After typing everything out on that, I wanted to work on my ReadMe because it was looking pretty sad and boring. First to please my OCD I set my badges in color coded order, added a table for core components and a quick start guide. The biggest and coolest thing I learnt today were ASCII Diagrams. With these I had Claude Generate them for my repo and I was able to change them around a bit. I first had one created of my whole repo layout with files, folders, and everything else. I then had some others created for power consumption, signal and data flow, and the Detection/Alert pipeline with push notifications. In the end I added my resources and credits for the thing I used in this project. Some of these things may not be correct though because I am not fully done with this project. I also want to thank my friend rishith for helping me organize my github, and learning from his ReadMe organization to make my own. Go check him out, he’s working on Prometheus right now, a fire drone: (@rishithc ).

Devlog #16: I probably should have done this earlier :(

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.

Devlog #2: a hardcoded threshold was never gonna hold up

yea so a fixed threshold on the emg envelope was never gonna hold up either.

went back and actually read the myoware docs properly instead of guessing, specifically https://learn.sparkfun.com/tutorials/getting-started-with-the-myoware-20-muscle-sensor-ecosystem/myoware-20-muscle-sensor, and turns out the board already outputs raw, rectified, and envelope in hardware, so i didnt need to build any filtering myself like i was planning last time. moved the wire off raw and onto env instead, watched the serial plotter, and it was night and day, clean baseline, clean spike on a clench. set a threshold in like ten minutes and called it a win.

came back after a break, restuck the electrodes in about the same spot, and the same threshold either pegged “flexed” the whole time or sat dead flat no matter how hard i clenched. also never wrote down where the gain trim pot was set the first time, so i cant even get back to the “clean” version on purpose right now, im just turning a knob and hoping. so, cool, a threshold that only survives as long as i never touch the sensor, my arm, or the pot again.

turns out this isnt just a me problem either, apparently even coapt’s commercial emg prosthetics need frequent recalibration for the exact same reason, contact impedance just isnt stable session to session for anyone. so a fixed number was always gonna break, i just hadnt hit it yet.

but yea, overall today i felt kinda dumb for thinking “clean signal on the plotter” meant “done,” and now im thinking the real fix is a calibration step that runs every time i put it on, flex hard for a sec, relax for a sec, threshold off whatever that session actually measures instead of a number i picked once and forgot about.

Devlog #1: eyeballing raw emg was never gonna work

yea so trying to read raw emg by eye and call it a gesture was not the move.

started by digging out a myoware 2.0 i had left over from a old project, strapped the electrodes to my forearm and wired the raw output straight into an esp32 adc pin, no shield, no filtering, just wanted to see what a fist clench looked like on the serial plotter before doing anything smarter. flexed a few times expecting clean spikes i could just threshold.

instead the raw trace was just noise on top of noise. every tiny arm movement gave a spike that looked identical to an actual clench, and the esp32’s adc added its own jitter on top of that. so, signal soup basically, couldnt tell a real flex from garbage.

so i backed off and started looking at how people actually do this instead of freehanding it, found stuff like https://github.com/csce585-mlsystems/EMG-Based-Hand-Recognition which bandpass filters and extracts features before a classifier ever sees the signal, plus a bunch of stuff training on the ninapro dataset that everyone in this space seems to use.

but yea, overall today i felt kind of dumb for expecting raw signal to just work, and now im thinking the real first step isnt gesture classification at all, its building the filtering/envelope pipeline properly before i touch a single label. UI code linked below

Devlog #15: training my own model wasn’t the move

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.

Devlog #15: training my own model wasn’t the move

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.

Devlog #11: started the new CV code, deciding on the approach

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:

• tensorflow + mobilenet-SSD — a proper deep learning object detector. heavier, but it actually learns what fire looks like, so it should handle different lighting and angles way better.
• regular opencv + a few libraries — lighter and simpler, runs easy on the Pi, but less robust.

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.

Devlog #14: building the dataset + training a tensorflow model

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.

Devlog #14: building the dataset + training a tensorflow model

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.

Devlog #13 : built a fire detection system for my drone’s Pi

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:

1. grabs the warm/bright pixels (orange/red/yellow in HSV, plus an R≥G≥B rule so it’s actually fire toned, not just bright)
2. flicker analysis over a few frames. ts is the part that matters. real flame shimmers frame to frame, a static orange thing (a ball, a jacket, a sunset) doesn’t, so it won’t false trigger on every orange object it sees
3. debounces over several frames so one noisy frame can’t trip it
4. spits out a 0-100% confidence from area + flicker + persistence

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. 🫡

Devlog #9: learning the AI side + designing a custom PCB

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.

Devlog #10: motor test issues and a flight controller swap

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.

Devlog #12 : scrapped my CV code, went full YOLO

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.

went down the YOLO rabbit hole

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.

side quest: mediapipe body tracking

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.

hardware: turned my ceiling into a drone

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.

next up

• train the YOLO model on a proper fire dataset
• run it against the ceiling cam footage
• check fps on my laptop vs what i’ll realistically get on the Pi

🫡

Devlog #12 : scrapped my CV code, went full YOLO

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.

went down the YOLO rabbit hole

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.

side quest: mediapipe body tracking

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.

hardware: turned my ceiling into a drone

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.

next up

• train the YOLO model on a proper fire dataset
• run it against the ceiling cam footage
• check fps on my laptop vs what i’ll realistically get on the Pi

🫡