On Successful Failure

Some of you may know that I have become a drone builder in the past couple of years. I worked with a friend to build Aerosensor Northwest, which was a service business intended to use data from unmanned aerial vehicles for scientific and land management purposes. I have no idea what happened to that friend; he has not communicated for months. This makes me sad, but I know I did my part to get the business to work. I don’t know if he knows that. Now I work for another drone business. They sell drone systems as a product. Making a drone systems as product is entirely different than making one as a service based deliverer of data. For one, reliability becomes paramount. For Aerosensor, I built 6 dollar airframes, knowing full well that that 10 flights was a good service life. Now I build airframes that are designed to survive for hundreds of flights at the hands of customers who may not know how to protect them from pilot error. Two different disciplines.

My boss knows exactly what the two disciplines mean. The owner of the company – not so much. I walked into a situation that was controlled by baby engineers – still students in official terms – who didn’t know how to actually build anything. ¬†They worked in the land of CAD, which is a very useful tool, but without some understanding of how to build and the costs associated with those processes, is actually worse than useless. They had been on a mission to make everything harder and more expensive than it actually needed to be. I’ve spent the last four months cleaning up the mess of theoretical engineering fantasy land.

Today, we tested the end result of that fantasy. Did the UAV fly? No. So a very quantifiable failure. Did the UAV fail in exactly the ways I expected? Yes. So it was successful exercise, and with proof in hand, we can now move on to solve what I already understood to be the problems with the system. A good day, all-in-all.

Leave a Comment