For those unaware, XPRIZE is a non-profit organisation which runs multi-year competitions with large prize pools targetted at solving the world’s most pressing problems.
One of these competitions was XPRIZE Wildfire, a four-year long competition to tackle wildfires with an $11M prize purse. It consisted of two tracks - track A (Space-Based Wildfire Detection and Intelligence) and track B (Autonomous Wildfire Response).
A team from my university had been participating in track B, and reached the semi-finals of the competition; unfortunately, they did not get through to the finals. Except, with only six weeks before the finals, one of the finalists dropped out. The team was back in the competition with very little time to prepare for the mission day of protecting a area for 8 hours!
The team’s approach involves a set of camera towers that watch for and triangulate smoke, and nests of drones which are dispatched to potential fires for identification and supression.
One of the consequences of this last-minute change is that the team couldn’t use the drones they’d been planning on using, and instead had to use off-the-shelf DJI drones. One of the challenges presented by the use of these drones is that their standby time is not long enough to be sitting ready for the whole 8 hours; and the competition requires that the system be fully autonomous, so no one could turn the drones on manually. The drones themselves have no remote turn-on function, and so the team needed a solution.
At the time, I was working as a Research Assistant at the university, and my boss was one of the team leads. She approached me asking if I’d be interested in designing such a mechanism, with a warning that I’d only have a week and a half to design and build the system before I’d have to fly off to Alaska for the finals!
There were three different drone models being used - M300s, M400s, and Mavics. Each of them have different designs around their power buttons so needed custom mechanisms. Each mechanism is roughly the same in that it consists of some way of mounting a servo over the power button such that it can rotate its horn into the power button to turn on the drone.
The M300 was the easiest design, so I’ll go with that first. There are four M3 mounting holes on the top of the drone, they’re unfortunately on the opposite end to the power button, so there’s a big length of unsupported plastic to reach the power button.
The M400 unfortunately has the power button located on the battery pack instead of the drone itself for some reason, so the mechanism becomes a bit harder to design. On top of this, the mounting holes are on a different side of the body to the power button. The original design I made had the mount go up along the side, then there was a pivot hinge connecting onto the servo-mount platform which allows it to be swung out the way by hand to remove the battery.
The Mavic also has the power button on the battery pack, and is small enough that it doesn’t include mounting holes. The solution here is to make a tiny mount that’s pretty much just enough to hold the servo, and is curved to match the curve of the battery. Then we used car moulding tape to stick the mount onto the battery pack.
Ok so we have a servo on each drone which can press the power button, but we need some way to actually control these servos. One solution would be to have some sort of wireless control system on the drone itself, but this makes everything a lot more complicated. We’d need a controller for each of the 20 drones, power for each, and a reliable communication method to each one. We’re also then adding a bunch of weight to each drone - reducing our flight time.
What I went with was a design where the cable for the servo runs down the side of the drone and is terminated with a magnetic pogo connector (like used to charge smart watches). This connects to either a 3.2m or 5.4m cable (depending on the drone’s location in the layout) to ensure a minimum separation between each drone. The cables are held to the ground with ground pegs, and so when the drone takes off the magnetic connector drops away.
Our setup was split into two nests of up to ten drones each, so we have two main controller boards. The controller board consists of a Pico 2W and ten JST connectors linked up to the PWM outputs, plus a Schottky diode between the 5V rail and the Pico’s VIN to prevent the servos being powered by USB power and ensure it’s instead powered by the 5V power supply.
Powering on a drone involves telling the Pico the port index and the drone’s model (different models need different rotation angles). The original plan was to have the Picos connect to a WiFi network and expose a HTTP endpoint for this, but to reduce failure points I switched to USB communication, so the Pico is plugged directly into the ground station. This was a surprisingly difficult tasks - the Pico uses the USB serial connection as a Python REPL and expects you to use the TX/RX pins if you want to do your own serial. The simple but eyebrow-raising solution to this was to actually just send raw Python code over the serial connection which imports and calls the module stored on the Pico.
Flex in M300 mount due to distance (printed some at higher infill/walls). Difficulty lining up holes perfectly.
Flex in M400 joint.
I had only two and a half days to assemble both of these nodes, plus terminate 20 of the cables, and 20 servos. My previous experience with electronics has all been as a hobby, so my wire stripping had been done by carefully applying pressure with wirecutters. For this I was working in a university lab, so I had proper tools - and learning that self-adjusting wirestrippers existed was lifechanging.
Due to drift from the drones on takeoff/landing we wanted 3 metres between each drone/any other obstacle.
Thank god for auto wire strippers.
M300 flexing, used car moulding tape (also for mavic attachment). M400 mount flexing on hinge.
The night before the finals day we were still out doing last minute testing/fixes at 9pm, and it had started raining… We started another test run and when the logs said the servo had been told to power on nothing happened. I went and grabbed the board out of the big plastic box it was in and plugged it into my laptop - nothing showed up. Out came the multimeter, but I couldn’t tell anything beyond the fact that it was still getting 5V to the correct pins. A visual inspection didn’t show me any water. There were two failure modes I’d thought of in terms of water - water shorting the ends of the cables, and water shorting the board itself. Since I couldn’t see any moisture on the board, and the cables were unplugged, my hypothesis was that the ends of a cable had stayed shorted for long enough to cause permanent damage to the board.
As a last ditch attempt at a fix, we figured we should at least try and dry out the board, so rigged up a very sophisticated drying solution based on the tools we had at hand (see pic below).
Yes, that’s the power leads of the board wrapped around the indicator stalk in a car, holding it up in front of an air vent at full blast. Anyway, we let it go like this for about 20 minutes, and when I plugged it back into my laptop it showed up!
Water-damaged board, car air conditioning (add pic).
During my first full day of testing the system with everything attached, I had an intermittent problem where the Pico would stop showing up as a USB device, and in order to fix it I had to disconnect it from both USB and the 5V power supply. Our power setup was such that we had mains power coming from a diesel generator, which went into a 5V 10A power supply, which then went over to the board. In my mind there were two potential causes, some weird behaviour from the power supply itself, or some safety shutoff being tripped by fluctuations in the power from the generator. It was hard to tell because the problem only happened a few times, but it seemed to coincide with our Starlink internet (run from the same generator) going down, so the problem was probably with the generator. But regardless of the cause of the problem, the system was failing to come back automatically.
If this happened on the day, we were screwed, an unresponsive board meant no drones getting off the ground! In the end, we decided the best solution was to eliminate as much unreliability in the power supply as possible, so instead of running from mains, we bought a couple of 12v car batteries and got some voltage regulators from the incredibly helpful UAF Makerspace. With the system powered off of a very steady car battery (with a theoretical battery life of over a week) there were no more problems.
Running off generator power, had problems with pico getting soft locked until unplugged from both power sources. Just moved to independent 12v car battery.
Connected input of regulator to board instead of output, regulator happily passed the 12v back through the input. Thank god for spares.
Individual transistors per line Resistors to identify type of drone Current monitoring to identify failed actuation Waterproofing All of this in a properly manufactured circuit board