___ _____ ______ ________
|\ \ |\ _ \ _ \|\ _____\
\ \ \ \ \ \\\__\ \ \ \ \__/
\ \ \ \ \ \\|__| \ \ \ __\
\ \ \____\ \ \ \ \ \ \ \_|
\ \_______\ \__\ \ \__\ \__\
\|_______|\|__| \|__|\|__|
This project is a sort of continuation of my BLDC motor controller project!
I’ve wanted to build a drone for quite a while now. Previously, I took my first step by building an ESC from scratch to help my understanding of how BLDC motors are controlled. This summer I have built a complete quadcopter from scratch. See it below!
A quadcopter is a drone with 4 fixed motors on it in a 2x2 pattern. There are many other shapes possible for a drone, but this is by far the most common. Drones have many different sensors on them in order to determine the proper reaction to its environment and controller input.
It features a STM32 H743 processor at its core running the Ardupilot software stack. It also has a Raspberry Pi 5 8GB as its companion computer running custom code to control an Arducam camera for automatic in-flight recording.
The main components of any drone are:
I set out working on my drone with three goals in mind:
A drone is centrally designed around a few major parameters, which almost seem to be circularly defined at first glance. The battery cell count and capacity are some of the more complex choices in designing a drone.
The cell count determines what kind of voltage you are working with and therefore what motors and propellers you can use. It is measured as [x]s. A six cell battery will be 6s, as there are 6 lithium polymer cells connected in series. Each cell is approximately 3.7 volts nominally, so a 6s battery measures about 22.2 volts nominally.
The capacity measures the milliamp-hours of the battery, it measures how much current can be drawn at the battery’s voltage before being empty. As you increase the capacity, however, you also increase the overall weight of the drone. There is a careful balance to getting these right to maximize flight times, as you cannot simply use the largest possible battery.
Another problem is that you really can't start designing a drone by picking its battery because it doesn't have a lot of physical meaning until it is in the context of other parts. What's better is to start with the flight controller and ESC and then move to the frame.
To select a flight computer you need much less. You really just need to know the software stack and to have your goals in mind for the finished product. I knew I wanted a drone that would process a lot of sensor inputs and eventually fly autonomously, so I went for a STM32-H743 based flight computer. It's on the higher end of specs and can do a lot.
As for software there are a few options for different use cases. I went with Ardupilot because I wanted a more capabilities in line with a DIY/Research Drone. For pure flying or FPV, though, Betaflight or iNav are other great software options.
A lot of flight computers sell as "stacks", combining the flight computer and ESC (electronic speed controller) into one vertical stackup of two boards. This saved money and space for me. I chose a knockoff of the MicoAir H743 V1 Flight Computer with a Bluejay-4IN1-60A ESC from Amazon.
I knew I wanted a drone that could lift a heavy load and be quite powerful, so I selected motors that could handle a 6s battery. With larger drones—like mine—you want motors that will spin more powerfully and at a slower rate. There is a value that can help to estimate this, the KV. It roughly equates the RPM of a motor as its KV multiplied by the voltage applied.
More powerful and efficient motors with larger propellers lead to longer flight times with heavier loads. This is what I wanted, so I selected Surpass Hobby S2807 6S 1700KV Brushless DC Motors with this in mind.
$$ \text{RPM} = kV \times \text{Voltage} $$
With the motors chosen, I next had to look into propellers. These were difficult to precisely choose and I initially chose wrong. At first, I chose 7 inch propellers that had way too much thrust and made the drone uncontrollable. I needed smaller propellers that would have less thrust. Less thrust made the drone more predictable and controllable. 6 inches did the trick for me.
To prevent choosing the wrong propellers like I did, you should estimate your build’s TWR, or Thrust to Weight Ratio. The number can be used to estimate the category of a drone from being a puncy FPV drone to a super sluggish and stable Cinematography drone.
For estimating the TWR I used the website ECalc calculate it based on my motor specs, battery specs, and then I would set the propeller parameters as the independent variables. This gave me a good guess at what my TWR would be.
The real benefit of estimating TWR is to get a feel of if your drone might be too powerful or way too weak for your desired performance bracket. For me, I initially made my drone way too powerful and uncontrollable because I only calculated my TWR after I made the drone.
See above, the TWR with my initial build is estimaterd to be 6.2!!! That is absurdly high and explains my uncontrollable first few flights. The tool was explicit how my parameters were too powerful, and it would have saved me a lot of time if I had done this calculation before purchasing propellers.
On one of my first flights I set the flight mode to "Altitude Hold". Its TWR was so high that at hovering, the PID loops sent the drone flying uncontrollably high and I nearly lost the whole build.
So, I re-estimated my TWR with smaller propellers (dropped an inch), and yielded a much more promising TWR estimate of 4.4. When flying with the new parameters, it flew much better than my initial uncalculated build. It had more control and the PID loops were able to safely accelerate without loss of control.
The MicoAir H743 flight computer and Bluejay 4-in-1 ESC are the center of the electronics on the drone. The 6s battery XT60 cable is soldered onto the esc voltage input pads. It is very important to add a large enough bulk capacitor on the input leads to handle transient voltages. For my 6S drone, a 25V capacitor is too dangerous and a 50V capacitor was used instead. In my setup, which is common for stacks, the ESC steps the voltage down for the flight computer and peripherals.
The flight computer has multiple UARTs as well as an I2C bus and a CAN bus. I only use the UART and I2C in my case. Each sensor or peripheral connects to its own UART to get power and transmit data bidirectionally.
In the case of my Raspberry Pi 5 companion computer (more on that below), it requires a stable 5V and 5A input totaling at 25W. This is not possible to get from the standard UART 5V outputs, so you need a dedicated buck converter for this. I found a waterproof 5V/5A buck converter that outputs via USB-C which has been perfect for powering the Raspberry Pi 5. Without such a regulated source, the Pi experiences brown-outs (when the board doesn’t have enough power for all its functions).
Battery safety is something that was very important to me from the moment I received the batteries in the mail. There have been hundreds of cases of houses being burnt down because of LiPo battery explosions. Albeit most of them are because of usage errors, it still was a cause for concern for me.
My solution was to store and charge my batteries in a special enclosure designed to protect against and isolate LiPo events. It’s called a BatSafe and I bought it on amazon, many reviews show people who were saved by it, so it seems like a worthy purchase.
Without an enclosure, you definitely should use your charger to set the cells at a storage voltage, and make sure they never get overcharged nor undercharged.
My Mico Air H743 V1 flight computer has a built-in gyroscope, accelerometer, barometer, and magnetometer (compass). Its 2 IMUS are: BMI088 and BMI270. The magnetometer is the IST8310 and is very sensitive to EMI (electromagnetic interference) of which the motors generate massive amounts of because they’re inductive loads. The barometer is the DPS310.
As a result, I need an external magnetometer/compass. This is a very common issue and, in fact, most GPS modules include an external magnetometer to provide a more reliable compass data source. My GPS module works by connecting to satellites in orbit, and requires air-exposure to get a strong enough signal. I'm using the HGLRC M100 GPS Module that has an integrated QMC5883p compass.
I have a Time of Flight (TOF) sensor on the bottom of the drone. It works by shooting light and measuring the time it takes to return back to the sensor. Since the speed of light is constant, the sensor can be used to accurately measure the distance between itself and an object that would reflect back light. This is used in drones for more precise landing and autonomous movements.
Also in the setup, is an optical flow sensor which works by measuring the differential position relative to the ground to tell if the drone is moving and if so in which direction at which speed. It allows for indoor controlled/autonomous flight since traditional GPS will not work indoors. For this I'm using the Mico Air MTF-01P sensor which bundles optical flow and TOF into one sensor module.
A drone equipped with an accelerometer and gyro can fly, but without any location based flight algorithms. For instance, once you include a GPS or Optical Flow sensor you unlock the ability to use “Loiter” mode on Ardupilot. This is my most frequently used mode and it simply locks your drone in its current position unless you specify a movement. If your sticks are at center, the drone auto corrects its position to hold itself still using GPS or Optical Flow. See more about flight modes here.
In the future I plan to add a LIDAR sensor for full directional awareness. It basically is just a TOF sensor that rotates around very quickly to get a 360 degree TOF reading.
This was the part of the project I had the most difficulty with setting up correctly. After looking into the radio options available, it seemed that the ExpressLRS protocol was a clear winner from how dialed in it was for drones. It has exceptional distance at the 2.4gHz frequency and quite a high bandwidth for sending large packets.
In my build, I had a small ELRS RP1 transceiver, which acts as both a transmitter and receiver for a two way comms link.
This is for Ardupilot only The ground control station is usually a laptop setup so you can view the gps reading, sensor outputs, and error/comms traffic. It’s great for debugging any problems you’re having when flying.
I use my laptop running linux with the QGroundControl software, rather than the normal MissionPlanner Ardupilot software. They both work well but QGroundControl works better on my OS.
So the setup is as follows, my controller is an EdgeTX Radiomaster Controller setup in mavlink mode. It creates a wireless network that my laptop can connect to and that my drone automatically pairs to. Once connected my drone wirelessly sends data to my controller and then my laptop as well. Here is the webpage that helped me find how to set this all up in MAVLINK mode.
A companion computer for a drone is a secondary computational device used to offload some heavy work from the main flight computer. In my case I have a Raspberry Pi 5 with 8GB of ram. I use it to record and encode video to a .mp4 video file. The Raspberry Pi is connected via UART to the flight computer and runs a custom python script to establish a MAVLINK connection to the drone.
MAVLINK is the communication protocol used on top of UART or RF to transmit data for Ardupilot. Using it in my script allows me to listen for specific commands and setup the Raspberry Pi to record video any time a flight begins and stop recording when it lands.
To get the Pi and the Drone communicating I wrote two scripts with Claude Code.
The scripts can be found here on my GitHub
Below is a video of myself (and my lovely assistant) flying the drone in my local area
This is a very exciting setup that can be massively expanded. During High School, I worked with April Tags for FRC robotics. It would be very interesting to allow the drone to autonomously fly using the aid of April Tags as a landing pad reference point.
This project was heavily worked on using OnShape, a free online parametric CAD software. I used it to make mounts for sensors and the electronic components on my drone.
What made OnShape particularly useful for me was to model the entire project and see how things fit together. Rather than just measuring and modeling a bracket, it really helped to model the entire drone so I could get a sense of how everything flowed together. It saved me a lot of time and prevented errors before I would send the prints off to my 3D printer.
I used my Bambu Labs P1S printer to 3D print everything in this project.
Specifically, I printed:
As for materials, I used a roll of Inland Transparent Polycarbonate filament (no carbon fiber) for structural parts as well as a roll of Overture 95A Red TPU for sensor mounts.
The battery bracket was a very necessary print because of how large and heavy my battery was. Without it, the momentum of a rough landing would move the battery, offsetting balance. I initially printed it using PLA, which cracked after 3 or so landings. After switching to Polycarbonate, however, I have not seen any damage at all to it. I was really quite shocked how strong polycarbonate prints can be without being excessively heavy.
To anyone working with drones and 3D printing, I really suggest trying it out.
The initial flights with the drone were not great. At first my propellers were flipped so the drone wouldn’t take off. Then the motors were shifted in the software so the drone was always rotating along its yaw axis. Below is a video of my first "working" hover test.
As you can tell the flight was not perfect. That video was while my props and motors were swapped, so the drone hovered but it was stuck spinning along the yaw axis. The yaw spinning scared me and I emergency stopped it. It drifted significantly because of its untuned state and so it crashed on the side of the table rather than landing where it took off.
Then I had the problem with my TWR being much too large. After these issues, though, the drone was somewhat steady in flight, albiet still shaky. It would hover and I could set its flight mode to altitude hold, locking its height. This worked, but not perfectly, and so I needed to tune.
There are so many ways to tune an ardupilot drone and so many tools for doing so. I followed a playlist from Chris Rosser as best I could and then used the Quiktune tool from ardupilot to finish it up. The results were very impressive. The drone was quieter, more steady, and draining less power in hover.
To sum up my suggested Further Reading/Watching:
Overall, this project was a success and I have a few directions I’d like to take it in the future: