FIGURE 2.4. The lifecycle of evolving robots. Although all the behavioral interaction and selection in the population occurs when autonomous and embodied robots are competing (dark gray pie slice), their lifecycles also involve complex genetic interactions that occur in software (light gray font). Who gets to mate is based on evolutionary fitness as judged by a predetermined set of rules (the “fitness function”). Because the genetic interactions involve processes like mutation and mating, the genetic instructions for the next generation of robots are the outcome of random processes (mutation, mating) and nonrandom selection. One spin around the lifecycle equals one generation.
That left us with the task of designing our first biorobots. Let’s engineer some players for the game of life.
Chapter 3
ENGINEERING EVOLVABOTS
“IF YOU UNDERSTAND IT, YOU CAN BUILD IT.”[10] THIS IS THE engineers’ secret code. It is so secret, in fact, that I can’t be sure that it’s real. No engineer has ever said this to me, a non-engineer, but I’m guessing that it’s the last question on every licensing exam and is whispered during their secret handshake.
Regardless of whether they say it, it’s definitely how they work. I figured this out for myself, having worked with many of them over the years, building robots. Engineers decide what their device should do—they understand it—and then they build it. Not surprisingly, that attitude drove me crazy—I was working and thinking in the opposite direction. At one company’s early design meeting, in which the hardware, software, and mechanical engineers were pressing me for specifications, I let loose my exasperation: “Let’s build the robot and then see what she can do! If I knew the specifications, then I’d know the answer. What we are doing is testing a hypothesis!” Silence. With eyebrows raised and knowing looks exchanged, the three engineers politely ended the meeting with a collective, “We’ve gotta get back to work.”
This left me sitting with an old friend, Charles, a.k.a. “Chuck” Pell, a chief designer at the company and someone trained as a sculptor and not, I began to appreciate, as an engineer. He interpreted. Chuck explained that engineers never use the word “hypothesis,” were never taught about how you test one, and were, instead, trained to build contraptions that work to do a job. The job that a contraption does, he continued, is defined by the specifications. So most engineers are literally lost without the specifications. You can’t get somewhere without knowing where you are going. This all makes sense, I conceded. But it doesn’t tell someone interested in evolutionary biorobotics the first thing about how to proceed. Damn the code![11]
Or don’t. What I’ve learned since then—thanks to designers like Chuck and his band of merry engineers—is that the code provides a great starting point for any kind of design, even the crazy stuff that we do with evolving robots. In fact, implicitly, the code got us started in Chapter 2, and thanks to it, we now understand more about the game of life, evolution, and how we might go about simulating it. In this chapter we’ll stick to the code and go hunting for an understanding of something more elusive—the first vertebrate. Understanding those first fish-like vertebrates—what they looked like and how they behaved over five hundred million years ago—will help us design and engineer the robotic agents that become the players in our simulation of the game of life.
Designing evolving robots of any kind has a number of important steps. The first and the most important is not something in the engineers’ code, although I think perhaps it ought to be: naming.
I feel it’s my responsibility to point out that if you neglect this first design stage, if you think it’s too silly to spend time on naming your robot, then you’ll regret it. You’ll find that other people will automatically and impulsively toss out names as they encounter and work with even just the idea of the robot. And one of those names—invariably the one that repulses you the most—will stick.
If you follow the examples of roboticists before you, you’ll take one of three approaches to naming. Approach one, eponymism: name your robot after a famous person, preferably someone in robotics or artificial intelligence who is still living and can pay back the favor some day. Honda Motor Corporation took this approach when they named their bipedal spaceman-type robot “Asimo” after the great but late science fiction genius Isaac Asimov, inventor, among other things, of the Three Laws of Robotics.
Approach two, bionymism: name your robot after the animal that inspired it or the job that it does. Michael Triantafyllou at the Massachusetts Institute of Technology created the famous fish-inspired RoboTuna back in the 1980s. Bionymism, when applied to robots, often involves the creation of a portmanteau, the smushing of two words to make a new one. When smushing for your bionymistic robotic purposes, consider the common prefixes “ro-” and “cy-” along with the suffixes “-bot,” “-tron,” “-borg,” and “-droid.”
Approach three, acronymism: name your robot using an acronym that is a random letter string or, heaven forbid, an actual word related to your robot. The military loves nonword letter strings, like VCUUC, which stands for Vorticity Control Unmanned Undersea Vehicle. VCUUC, spoken as “vee-cuhk,” is the serious, naval stage name of RoboTuna. VCUUC is a kind of AUV, spoken as “eh-you-vee,” which stands for Autonomous Underwater Vehicle.
Now we are ready to tackle our “evolving robots.” We call them Evolvabots. We really went out on a limb and smushed, using the functional variant of the bionymistic approach.
Our Evolvabots need to be autonomous agents operating in an evolutionary world, but that’s not all we need them to be—we need them to address our specific hypothesis, such as the relationship between swimming ability and the evolution of the backbone. In order to create those specific Evolvabots and their world, we need to ask and answer a host of mission-critical questions:
* Which animal will we model and why?
* Which features of the animal will the Evolvabots possess and why?
* Which features of the animal’s world will we model and why?
* What is the selection pressure that we apply and why was it chosen?
* How does the Evolvabot and its world, taken together, represent the animal and its world?
* How will we judge if our Evolvabots are a good model of the targeted animal?
These questions are critical because their answers drive years of effort from a group of people, the research team. If you haven’t answered these questions carefully and used them to guide your design effort, then later, when you are done running your experiments and want to get your project published in a scientific journal, you may find your team saddled with a paper that is DOA.
These mission-critical questions hark back to the “why robots?” question of Chapter 1. You have to be able to show that your Evolvabots and the processes that are used to evolve them represent, in some way, biological reality. The important word here is “represent.” To represent is not the same as saying that you have to replicate exactly the actual vertebrate and its actual environment (i.e., you don’t have to make a cat to model a cat). Instead, you have to demonstrate that the decisions you made in designing your Evolvabots were not arbitrary. Time, equipment, money, and expertise will always constrain those decisions. But the knowledge of your target system must also guide those decisions: you have to show that features of your Evolvabot relate to—represent—features of your target.
10
Richard Feynman, the Nobel Laureate in Physics, said something similar: “What I cannot create, I do not understand.”
11
What’s really useful about the secret code is that it implies that if you can’t build it (whatever “it” is), then you don’t really understand it. This is another way of thinking about what people call an “existence proof,” which is the ultimate in physical evidence: if it exists, then it can exist.