An Exercise in Improvisation
I pulled into the parking lot of a nondescript suburban office building on a warm Saturday morning. Unremarkable on the outside—inside would be a different story. That day, we would fly robots, quadrotors to be more precise, using what engineering skills we could muster to automate their movements. Cincicopter was to be an exercise in testing the limits of our improvisational skills in an unfamiliar environment, but I think there’s more to it. There are direct applications to our everyday project work hidden in the world of friendly, flying robots.
The Idea
We came in with an idea: airlift a team of toy paratroopers over a target on the ground and drop them. Accomplishing that goal would require not just some custom software, but also hardware modifications to the quadrotor itself. It was an ambitious goal; no other team that day would modify their flying machine. The journey we undertook over the next several hours would prove just how ambitious it really was.
Solving Problems
Prior to the event, we had done our best to reduce this idea to the simplest thing that could possibly work, so we immediately set to work, familiarizing ourselves with the quadrotor and working through issues.
Problem 1
Our first flight met with disaster right on takeoff because the platforms we attached to it to hold the paratroopers prevented it from achieving a stable hover. Our first attempt to fix the problem was to pitch the aircraft forward to counter the balance problem. After repeated crashes, we realized that we needed less, not more, to return things to normal. We split the platform in half, mounted them symmetrically, and removed the software hack. Slightly crude, but it worked and let us focus on the next challenge.
Problem 2
Every part of our plan went through a similar progression. Initially, we wanted to mark a point on the ground with tape and utilize computer vision software to identify the mark. This turned out to be so ambitious we never even started an implementation. Instead, we discovered a built-in capability to recognize a calibration sheet that ships with the device. While this was less satisfying than learning how to identify ground features, it kept the project moving forward.
Problem 3
What would consume most of our day was how to get our paratroopers to fall gracefully from their platforms into the air above our target. Again, our initial thought was to program a sequence of maneuvers to jostle them free; however, we again utilized some built-in features of the aircraft software. This particular model comes pre-programmed with some aerial dance moves, a few of which reach altitudes where we could drop our toy soldiers.
The Takeaway
The takeaway here could easily be that simplification was the most important factor in delivering a working solution. This hack day was just that—a day—and what we had at the end was what we delivered whether it worked or not. Simplification was the tool that allowed us to exist within the time constraint. It forced us to set aside grandiose ideas in favor of what worked now. In this regard, is time constraint itself a tool? I’m not sure, but I do think it was critical to our success.
