As a roboticist, I love creating new and complex engineering systems, refining their capabilities, and making them work.  But believe it or not, I’m also excited when they break!  In fact, one of my main areas of research deals with theory and algorithms of detecting when something breaks, figuring out what is wrong, and determining how to fix it.  My interest in this regard is not about structural breaks, like snapping something into two pieces; rather, I study functional breaks, when systems and components operate in improper ways.

But believe it or not, I’m also excited when they break!

My work in this area began when I was an aerospace engineer, and it became the focus of my doctoral dissertation.  Today, I am blessed with a fantastic set of students who join me in researching this topic, developing new approaches for dealing with “broken systems,” and testing those approaches on everything ranging from underwater robots to NASA spacecraft.

As with any good area of research, our study of broken things begins with developing a theoretical framework for thinking about the functionality of a system.  This is a wonderfully difficult thing to do since such a framework defines the vocabulary, what exists, and the reasoning criteria for an area of study.  Ask 10 people what defines a “fault,” and you’ll probably get ten different answers.  Responses such as, “when something doesn’t work properly” aren’t precise enough; at the very least, you’ll need an exact definition of “properly working.”  In our work with industry, we’ve found a surprising level of imprecision and diversity in defining what it means to “not work properly.”  My favorite answer was from the head of BMW’s repair division who said, “anything causing a customer to bring in their car.”

I believe strongly in balancing the theoretical demands of an academic approach with the practical reality of creating useful results.  This has guided my group in developing a rigorous but grounded framework for thinking about the proper functionality of complex engineering systems.  This theory uses a logical “calculus” to define things like the “symptom” of a problem, a “diagnosis” consistent with a symptom, and a “resolution” that is a new configuration that re-establishes a system’s ability to do its job.  We have developed software using algorithms based on this theory so that we can analyze the performance of real, functioning systems. 

For example, my students apply this technique to taking care of a series of NASA satellites that we operate for our colleagues at Ames Research Center.  Our systems have caught cases of a satellite resetting itself and of problems with our ground communication stations.  For my students, this is an incredibly exciting and challenging way to test the validity of their research work.

So, the next time you mutter in frustration, “this thing doesn’t work,” think of me and my students, working late at night in the lab, breaking things, and loving it!