Skibidicopter Project Report

The parts arrived but didn't include the collets needed to mount the propellors on the motor shafts. They also didn't include a battery, which we had forgotten to order beforehand. We ordered a battery and propellor mounts from Amazon, but we had to wait till Monday for them to arrive.

One of the new motors had a different motor constant than the other motors, but we decided to deal with that problem in software.

The frame was missing screws and had mysterious, unlabelled ESCs that we weren’t too sure about. We swapped them with nicer ESCs we found, reassembled the frame with better cable management, and cleaned off adhesive residue and dirt.

Before soldering everything to the power distribution board, we validated that all 4 ESCs worked using a quick Arduino sketch.

We soldered the new ESCs to the frame's pads, but our iron couldn't melt the unleaded solder we had, so we had to use shit-tier leaded solder from an SMD rework kit, which didn't have a flux core. Consequently, the wires barely stuck and had flaky connections.

The Amazon packages arrived, but the prop mounts had the wrong diameter, so we submitted 3D print jobs to the library for inserts that would allow the propellors to screw onto the motors' threads. While designing the prop mounts, we modeled the entire drone in CAD, taking the opportunity to plan the layout of our electronics stack. Placement of the IMU in the center of the frame would make our lives easier later.

We wrote a quick program to test which channel belonged to which flight controller axis.

The prop inserts worked! We finally assembled our electronics stack and began mounting it onto the frame using a 3D-printed adapter. However, we soon realized that we had no bolts of appropriate diameter and length to mount our 3D-printed adaptor to the frame. Even after scavenging in the IEEE labs and Computer Security Lab, we couldn’t find any bolts that fit. Instead of bolts, we used a combination of wire ties, which fixed the electronics in place vertically, and long, thin bolts taken from an Intel NUC case, which aligned the electronics mount with the frame in the x and y directions.

We accidentally mounted the electronics to the frame 90 degrees from the correct angle, which meant that the bottom of the frame obstructed the downward-facing ultrasonic rangefinder. We didn't want to reassemble the entire thing, so we scrapped the rangefinder from our design.

We discovered that our barometer and IMU drivers, which we previously had declared 'working', were very broken. We spent ages staring at the typo-laden BMP388 datasheet before realizing that the driver code had some missing brackets.

This is partially Java's fault for not supporting unsigned bytes, but if we had to do this in C, half of these operations would probably be UB or inadvertently cause truncations to bizarre, 9-bit Honeywell characters.

The BMP388 has two modes: 'normal' mode, where it periodically takes measurements and stores them in a FIFO, and 'forced' mode, where it takes measurements when they're explicitly requested over I2C. Normal mode was really broken, probably due to a weird race condition somewhere, but we eventually got tired of debugging it and decided to use forced mode instead.

We finally hooked up the propellers to the drone and started working on code that would get the drone to fly now that all the helper classes were written and the sensor input was successfully converted into data useful to the flying algorithm. We applied the PID controller to send mapped throttle commands to the ESCs to balance on one axis. We started testing the code but ran into issues preventing all four ESCs from working correctly.

With hours left before the showcase, we called it quits and put together a demo of balancing on one axis using only two motors. At the showcase, we presented our real-time orientation renderer. The drone was too big to fly indoors anyway, but our classmates enjoyed seeing the live orientation demo.