After a week of being locked in, I think we’re finally close to finishing the drone! I’ve made significant progress with figuring out software, buying parts, wiring, and putting everything together. In this post, I’ll go over finishing the big prints, BlueOS, testing my new ESCs, and prepping some of the electronics which will be necessary for the final build. 

So, continuing off of my last post, I finally began the scary printing process of the back, top, and bottom shell pieces. I started with the two front pieces. I initially used Bambu Studio’s auto-orient feature, which I assume prioritizes minimizing supports, as it oriented the part with nose side down. Although I did find it a little iffy, considering the entire print would be held onto the build plate by a very small segment of purely supports, I went ahead with it. As expected the print failed about 10% in, so that was a good catch. After that, I ended up just prioritizing bed adhesion for the rest of the prints, orienting the part like in the below photo. 

After I had printed the two front pieces, it was finally time to move on to the largest print of the project, the back shell. It would take almost half a spool to print, which actually turned out to be a bit of an issue. Before I realized that I actually didn’t have enough yellow filament remaining, I had already let the print go overnight, meaning I’d eventually either have to pause the print, wait a couple days for more yellow filament to arrive then resume, or I’d have to switch the color half way. I decided that the best option would be to switch the color, as 3D prints, especially those of PETG tend to shrink after printing. Pausing for such a long period could mean that when the print job resumes, the layers may not align, which I decided was a worse outcome than just having a different color. 

So I printed the second half of the piece in black, and fortunately, it actually turned out to look pretty nice, kind of like a bee. 

The next course of action was controlling and programming the drone. At this point, my understanding was that because I was designing my own custom layout of motors, I would have to make my own custom firmware to flash onto the Pixhawk, then I would have to figure out all the separate programs and control systems for my Raspberry Pi. However, I then discovered while researching online that the specific locations of the motors don’t actually matter, but rather what matters is each motor’s control over the 6 degrees of freedom. I found that Ardusub actually offers a couple pre-made motor layouts, one of which actually was perfect for my project. I guess that’s the benefit of receiving design inspiration online; these designs exist for a reason.

Furthermore, I ran into something called BlueOS, which is an operating system specifically designed for ROVs, boats, and similar drones. With BlueOS on the Pi, I would be able to receive live feed from a camera, control the drone from its built-in ground control station called Cockpit, and also modify any parameters that need to be changed, just like in more popular control stations like Mission Planner or QGroundControl. 

So with all that new information, I decided to test a single motor using BlueOS. At this point, I had already assembled much of the 3D printed parts of the drone, and I wanted to test how the propellers would fare mounted to the drone. 

I used some temporary crimps to connect the 3 motor wires to the ESC, which was hooked up directly to a power supply. I then connected the ESC to the Pixhawk’s MAIN OUT pins. The Pixhawk was plugged into the Pi via micro USB to USB A, and the Pi was plugged into the wall. 

With this set up, I was able to connect to BlueOS through my WiFi and test my motors. At first, it went really well, with the motor spinning smoothly and the drone remaining intact. It was then that I realized my ESCs were actually non-bidirectional, meaning that it would only be able to spin in one direction, meaning I would have to buy some new ones. Fast forward a couple days, I recreated this system with the new ESCs, and they worked flawlessly. 

In the meantime, I worked on some of the wiring components I would need, primarily the battery leads and a parallel Y-splitter cable so I would be able to connect two battery packs in parallel. 

First, with the battery pack, all I needed to do was solder two wires onto the positive and negative terminals, and then the balance lead onto the positive/negative terminals + each connection between two batteries. To keep it neat, I fed balancing wires through the center of the battery pack and cut the closer wires to a shorter length. Finally, I designed some nicer looking endcaps for the batteries to ensure that none of the metal was exposed.

For the splitter cable, I started by soldering two black and two red wires together, which were then soldered to a single deans connector as if they were single wires. Then, I took one black and one red from each group and connected them to separate male connectors, which would allow for two batteries to converge into a single connector in parallel.