The Drone that Could [not, yet]
Motivation
I’m a programmer by practice. Since high school, I’ve written nifty apps and helpful scripts that tickle my brain. But there’s always been something missing: the physical aspect of creating. To finally work with my hands and make something physical, I chose to explore my interest in the intersection of hardware in software by making a drone. No biggie, right? Sure.
The Idea
Coming right out of Physics 140, I wanted to explore the concepts I had just spent a semester exploring. I wanted to see how gravity and thrust interact with each other — and maybe even get to the point where I can modulate the gravity of my drone, and make it act as if it was on Mars or Jupiter. I also just wanted to explore what it was like to build hardware. This would be my first foray into being hands-on with electricity. I wanted to experiment with what it mean to play with current, voltage, PWM signals, and PPM outputs. Or at least now I know that’s what I was going to be doing.
The Start
This was truly the hardest part — figuring out where to look and what to get. After a few weeks of just watching other people build homemade drones, I settled on buying a few parts: electronic speed controllers, motors, two Arduinos, and a gyroscope. With quadcopter theory about pitch, roll, and yaw in the very back of my mind, I got to testing. First testing one motor spinning, graduating to all four, and modulating their speed based on a connected joystick, progress was good. This was enough for me to build my own remote controller. I bought radio modules (and ‘borrowed’ some bluetooth modules from a lab).
The Middle
Things got spicy real fast. I opted to use bluetooth as it meant I could just code an app on my phone that would act as a controller, but it wasn’t until a few weeks in where I found out the bluetooth module’s Bluetooth 2.0 doesn’t work with my phone’s 4.0. From there, I pivoted to using old fashioned remote control radio modules. Key challenges in establishing communication were that the modules could only send one byte at a time. This meant joystick values that ranged from 0 to 633, had to be mapped to numbers 1–255, sent by the transmitter, received by the Arduino, and then converted into values the motor can understand from 0–1000. A slew of wiring issues, goofy mistakes, and plain old inexperience made this take way longer than it should have. Writing spaghetti code didn’t help. While this was in progress, I was laser cutting the body of my drone (shout out to the UGLI design lab).
Combining the two pieces of code that made motors run + transmit data from joysticks, as well as a lot of hot glue, solder, and screws + bolts we had the final product:
The Crash
So, yeah, it crashed. First test flight, the night before showcase, during a Shift jam session. It definitely flew…just into the wall. Luckily damage wasn’t too bad and should be pretty easy to fix: ~2 hours worth of work. The spaghetti code definitely needs some cleaning.
The Future + Reflection
This drone is extremely close to being done. The last few steps are definitely easier said than done, but very much in reach. Fixing up the code + body is all that’s left — stay on the lookout for a flying drone making an appearance in the slack :0
I won’t lie, I didn’t think it would be this hard, but I should have. Theres a lot of moving parts in this thing that really add to the complexity, but it’s been a fantastic learning experience. I’ve gotten to dip my toes into the world of hardware, and I love it (minus the crashing, toasting fingers on the solder machine, and tedious wire management). Aside from learning about voltage, current, and how easy it to blow things up, I’ve come away with a ton of skills like soldering, laser cutting, 3D printing, Arduino Code, and even a little bit of CAD.
— rohan
