Autonomous Robots: End of Life Dilemma

December 2012
By Bryan Bergeron

Science fiction authors have contemplated limiting the lifespan of autonomous robots for the good of humankind — take the replicants in Blade Runner that are engineered to have a four year lifespan and the replicators in Stargate SG-1 that have an unlimited lifespan. The conclusion seems to be that while individual autonomous beings naturally desire to live forever, such a condition is incompatible with humanity. Our resources — and eventually our autonomy — would be usurped by our robots which self-replicate themselves into superior entities.

Such considerations may seem impractical today. We celebrate when a Mars rover lasts several months past the planned failure date, and most of us strive to build robots that can survive a few accidental crashes, much less outlive us.

There are instances, of course, where forced death or destruction of our creations is warranted. Consider the aberrant autonomous missile that veers off course that must be destroyed with an auto-destruct instruction. I've always suspected some car manufacturers and electronics manufacturers design their products to self-destruct within a few days of the warranty expiration date.

However, if you take a look at what's under development in the research labs today — self-assembling nanorobots that can be sprayed onto surfaces of enemy aircraft to render them useless or injected into patients to seek out and destroy cancer cells — you can envision a time where limiting the lifespan of a robot or colony of robots may make sense. At question is how long should our creations be allowed to live.

Biological life is a cyclical balance of life and death. At the macro level, populations expand until the food supply is exhausted, populations shrink and the food supply increases, allowing the population to expand, and so on. In our bodies, normal cells have a finite lifespan, as encoded in our DNA.

A red blood cell, for example, is good for about 90 days and then it begins to self-destruct. Macrophages — large white blood cells — can detect damaged red blood cells and remove them from the blood stream.

However, occasionally cells in the blood or elsewhere in the body manage to defeat the encoded self-destruct instructions and grow unabated. Unfortunately, this cancer is usually at the expense of other cells and the body as a whole.

So, again, to the practical implications, what's the take-home message for the typical robotics enthusiast? Well, if you're working with autonomous swarms — or even just a pair of carpet roamers — can you devise a way to let one signal the other that its systems are failing? The 'failure' could be as simple as an RTC (real time clock) chip connected to the microcontroller in one of the robots.

When the time is up, the "hurt" robot transmits a signal — say an IR stream — that the other robot must intercept and decode.

How the second 'helper' robot responds is up to you. If you're of the battle-bot mentality, then perhaps a quick blow by a hammer is appropriate. Or, perhaps you can devise a means of connecting the two systems together for recharging the 'sick' robot — think in-flight refueling of an aircraft or quadcopter.

Now, consider how a swarm of autonomous quadcopters could remain aloft and 'stealthy' without need for intervention from ground control. The 'tanker' drone — equivalent to the macrophage in the blood — would either destroy a damaged quadcopter that's a danger to other copters in the swarm, or charge the battery of a nearly depleted copter.

The signal for destruction could be generated by the microcontroller of the damaged craft or come from, say, sound sensors on the tanker drone that detect grinding in a failing motor.

Such a scenario isn't as far off as you might think. Today, it's common practice for R/C controllers to have a fail-safe mechanism that's activated when there's a loss in received signal. Common options include cutting all power (sudden death) and cutting power to half (controlled crash).

Of course, you can also program the microcontroller to execute a number of other options, such as circling until either the battery is depleted or you've moved closer to the craft.

Can you think of other, practical scenarios in which death of a robot is necessary and beneficial? As the sci-fi movies have shown us, there's no time like the present to get a handle on self-destruct mechanisms for your robotic creations. Later, you may not have an option. SV