For the final in DESINV22 my partner started by building a drone, this chronicles its design process.
Building a drone requires a healthy mixture of precision and planning. As such, much of the first weeks working on our drone were focused on designing a circuit to precisely modulate motor speeds, and prototyping various frame designs. Our initial frame design was a small, 3D printed, rectangular body designed to snap the motors  in for a clean fit. It  included a honeycomb cut-out pattern for weight reduction with minimal strength loss.
In addition to modeling and printing the frame, we also laser cut scale replicas of all of our components with cardboard, allowing us to properly evaluate frame size constraints. Ultimately, the initial frame was too small, and we found that the honeycomb structure added weight with few advantages over support beams crisscrossing the frame. These considerations led us to our next iteration on the frame, a circular one seeking to remain light, while also being equally if not more structurally stable. Variations of the circular frame design are shown below alongside a print of the initial frame design.
With the frame design more or less locked in, we began working on the system that would balance the drone as well as the one that would control the motors. In line with our efforts to minimize costs for the project, we decided to use 1600 khz motors with an 8.5mm diameter. Our research suggested these provided the best balance between cost and price. The power draw of our motors far exceed the power output of the Adafruit Feather BLE we were using, so instead of powering the motors directly, we wired the Arduino to four MOSFET transistors that could be made to modulate the speed of the motors. A circuit diagram, as well as a test circuit on the breadboard are shown below.
Having built a working version of the circuit, the next step was to write and test balancing software. We ultimately decided to write our own software, as opposed to using an online library for the two following reasons. First, our hardware setup was specific enough that using prebuilt flight controller software would involve significant doctoring of the code. Second,  while building a drone a good enough project by itself, there was a substantial learning opportunity in writing the software to fly it. As is conventional for quadcopters, we implemented a PID controller to fly the drone.
A PID controller takes user input on the desired state of the drone, calculates errors using data from the onboard sensors, and responds accordingly as a function of the amount of error, how fast the error is changing, and how much error has accumulated over time. For our onboard sensors, we decided to use a MPU6050 five axis accelerometer and gyroscope. While this was unable to inform us of the altitude of the quadcopter, it was low cost, and was able to output fairly accurate data about the drones orientation in space after much tuning.
In order to prototype the software and circuit, we then built a single axis balancing platform for the drone. We used a skateboard bearing connected to a piece of wood that approximately simulated the width of the drone with motors mounted to its ends. With the sensors mounted we were able to tune a simple two axis PID for the drone.With careful tuning we were able to balance the platform and adjust for interference and nudges from its environment.
While informative, and fairly useful, this prototype proved to be fairly unsuccessful in simulating actual flight conditions. This was because there exists substantially more friction in a cheap skateboard bearing than an airborne drone. Balancing  one axis in an environment with decent amounts of friction proves to be trivial compared to the undertaking that is actually getting a small quadcopter flying. It also requires a much lower refresh rate of the PID loop which came around to bite us later in the project as we later had to almost entirely rewrite Adafruit's bluetooth code to speed up our flight control software.
Having prototyped the software, circut, and frame, we set about constructing iterations of the actual drone. Over this process we increased the height of the chassis to make it more rigid, and developed better ways to secure, and miniaturize the electrical components of the drone. We also experimented with an alternate, propellor design with four shorter blades, meaning more lift, at the cost of a lower speed of rotation. After only a couple iterations, we were able to arrive at a point where we were content with the hardware, and began the process of tuning the drone.
We began tuning the drone by rigging the drone inside a cardboard box with string and playing with PID constants to get it to fly. This showed that the drone had more than enough power, but, not unlike the previous balancing prototype, proved to be fairly unhelpful in tuning the PID. This is because in the box the drones movements were constrained, meaning that it couldn’t get exceed a certain amount of misalignment before the string caught it, and the drone could lean on one side of the strings, leading to false positives when the drone in fact was only successfully balancing one side of its chassis.
In the end, the drone never flew in any meaningful, or controlled, fashion. Even more frustrating is that were not sure why. We suspect the following were our biggest issues:
1 - Despite spending a substantial amount of time optimizing the PID loop, latency issues with bluetooth meant that the PID loop only ran about 170 times a second. Using a faster chip would make balancing easier.
We failed to build a proper system for organizing the wiring, as a result the center of balance on the drone tended to be skewed one direction or another, and lacking a good way to secure the batteries meant that the batteries were likely shifting slightly during the flight.
2 - The propellers likely become more and more out of balance as the drone was crashed over and over again during tuning, and the frame certainly warped as well. Further, the limitations of 3D printing meant that the motors didn’t always connect to the frame properly, sometimes coming out at an angle, rather than facing straight up properly. While, by themselves, these are fairly small issues, their cumulative impact was probably substantial.
Frankly, this project isn’t done yet. It needs more work, and in many cases, redesign of its systems to increase the precision or the wiring and weight distribution, but it was a learning experience. We entered this project having never used a transistor before, and exited with a working knowledge of drone hardware, and having written our own flight control software. We didn’t end up with a functioning drone but learned a lot in our failure.
Back to Top