PCB v4 in KiCadThis week I'll be continuing the drone from last week. What went wrong last time? PCBs v1, v2, and v3 all had shorting issues where a motor was either driven high constantly, never turning on, or stealing power from the microcontroller.
So what did I change in v4?
PCB v4 in KiCad
Well apart from embracing double sided PCBs and making the traces more spaced apart thanks to the freed space, I changed my milling method. Notably, I used 1/32" in addition to 1/64" end mills. I repeat, do not use 1/64" end mill exclusively. I used the Bantam Tools mill, which is especially nice because it will calculate which traces require the thinner tool. Then, I meticulously checked and cleaned every single trace on the PCB under the microscope, using tweezers and compressed air to remove debris. Finally, I probed the pads with a multimeter to check for any shorts. All of this before putting on any parts.
So you would think it worked first try?
Everything that can go wrong, will go wrong.
The first issue I ran into was the ESP32's GPIO pins seemingly not turning on. Despite being able to flash code and respond to serial, the microcontroller did not want to execute code. Anthony suggested strapping Pins might be the issue, which pointed me in the right direction. For whatever reason, one of the pins I'm using must be driven high at startup or the ESP32C3 will not execute from flash.
Since I have four 10kΩ pull-down resistors in my design, I investigated those first and... somehow a bit of solder flowed around three of the four resistors and effectively shorted them. This would've probably been a big headache later on, and it fixed this first issue!
So watch out for strapping pins!
Great! Now the microcontroller works, and so do the four motors! What could possibly go wrong?
How about everything (MCU, motor controllers) breaking during the fourth test. Not only did the battery no longer power the microcontroller, but using USB and the battery would not turn on the motors. And this happened without any changes or damage.
So what happened? Well motors consume a lot of power, on the order of 1A each. And each copper trace on my PCB can probably handle that without much trouble, but two traces in particular have to handle much more: Ground and BAT+. The motors are routed in parallel but the junction happens after a long, thin strip of copper down the middle of the board so that one burnt completely.
The fix would be to redesign and mill the PCB, or add jumper wires with adequate current ratings.
Don't run lots of power through thin traces!
Somehow the trace to power the microcontroller also burnt. I'm not sure how, it really shouldn't be drawing that much current. It'd be nice to apply the same fix as before, but the burn happened underneath the MCU (BAT+ pin isn't exposed) and would be impossible to fix without desoldering a lot of things.
So I connected BAT+ to Vin, which works but has the disadvantage of removing the option to power the drone using both USB and battery.
Pretty self explanatory. There's a ton of vibration in the frame design, so that's probably a bunch of energy wasted and more current drawn.
Finally! The electronics work. So we can move on to flight software, starting with the IMU.
I'm using the MPU6050 which is relatively cheap (and old) but has an onboard processor (DMP) that performs sensor fusion for me. That's nice because the ESP32C3 is single-core and will eventually have WiFi bottleneck issues.
The reason I'm using the ESP32C3 and not the RP2040 or something along those lines is for its wireless capabilities. I want the tuning software and remote control to be a website. I implemented this in two ways: either the ESP32 acts as an access point (i.e. it becomes its own WiFi network) or joins the same network as my laptop (e.g. "EECS_Labs"). Both work and it's a tradeoff of boot-up speed or connection speed.
Either way, the ESP32 hosts a website which I can access via its IP address. Then, that website opens a WebSocket that I use for bidirectional communication (i.e. user commands <-> telemetry).
Here's a demo of this working. The drone is just spamming the console with its orientation... wirelessly!
Probably the biggest advantage to using a website rather than a standard RF controller is I can add anything to it. For example, the PID constants can be tuned wirelessly and without flashing.
Also, what is PID? It stands for Proportional, Integral, Derivative. It approximates the problem of balancing our drone (motors are not made equal. Powering them all will not result in stable flight) using a linear model of the error on each of three orientation axes: yaw, pitch, roll. This is called closed-loop control, as opposed to open-loop which is like driving with your eyes closed (a bad idea).
It's a little hard to convince this on video, but here the left-most motors increase in speed to counteract the orientation shift.
Things went well but it's all downhill from here.
While tuning the PID, the drone flew off into my arm (it hurts ;_;) and broke one of the motor controllers.
One of the MOSFETs blew clean off!
Above is the voltage across the ESP32's power pins. That sudden drop is when the motors turn on, which is enough to reset it. This is due to the motors causing a sudden current spike (stall current is significantly higher than constant) which drops the voltage sufficiently to reset the ESP32. I could fix this with a buck converter or better battery, but I didn't have time for either.
So behold this monstrosity:
It kind of defeats the point of being wireless (which it still is, technically!) but I powered the drone using a desktop power supply at 3.7V, 3A MAX.
Anddd the topping on the cake is this:
I dropped the drone during testing and another motor broke. At this time, lab was closing and I had no way of fixing this. So the drone may not fly today, but hopefully in the future!
I thought making a drone would be a battle split between hardware and software. Apparently not, because electronics is really difficult. This is a failure for today but I will be back B)