Darwin at Home

Evolution brings a generative process into contact with a selective process, and before we can do any productive thinking about what might constitute fitness, we have to get the generative process working. Before we can evolve tensegrities we have to be able to grow them, and last time I explained that I felt unprepared to do make the next step, so let's extend this prerequisite: Before we can grow tensegrities we have to be able to build them by hand.

So I took the challenge of putting a new version of Tensegrity online for myself, Hans Moor, and the rest of you to play with so we can all get a real feel for what tensegrity is like. Please take some time to play around with it a bit, and let me know what kind of feeling it gives you and what it makes you think about or what questions come up in your mind.

http://www.darwinathome.org/tensegrity-20080217/

This version is by no means refined to be idiot-proof, so don't expect it to seem finished. I did come up with one really nice interactive feature, and that is the highlighting of triangles where the building will happen. The code for this is quite nice, but of course the way it works is most important: when you see a triangle highlighted, you can click your mouse button and a new tensegrity module will appear! Enjoy experimenting with the program, and let your imagination wander.

Yesterday I once again participated in the very fascinating Biota.org Live radio show podcast and delving into the idea of Intelligent Design with the four other guys and how it applies to ALife developers like us. I talked about how I think it's a perfect description of what we do, and that our artifical life efforts only serve to elucidate the absurdity of the religious notion of Intelligent Design. The challenge that we seem to have taken on is to design intelligently enough that the design becomes intelligent in some way, or in other words to build something that surprises us. I make the point that it's very hard to prove to yourself and to others that you have built something that doesn't need your steering, but it's somehow autonomous instead.

I also mentioned that I'm very reluctant to call something intelligent design or artifical life until it has really surprised me. Currently with this tensegrity project we are not yet even approaching evolution yet. Instead we're still taking steps towards developing the generative growth processes.

One thing that I finally got right this week (actually at 1am saturday morning!) is the physics of the rigid bars when they hit the ground. A while ago I set it up with antigravity below the floor, but that really didn't work well. I kept seeing unwelcome artifacts of the physics appearing, and more recent changes have left me with tensegrities spontaneously scooting across the floor instead of coming down to the surface with a thud. The way I solved the problem was, upon floor collision, to eliminate the component of the other joint's velocity pointing in the direction of the bar. This was exactly the "thud" that was missing. They now act exactly like rigid bars.

Last time I talked about reducing degrees of freedom in the tetra and now the simplicity that this has added to the model is starting to pay off. There's one thing from last time that I got wrong, and that's the name "tension factor". The lower the tension factor the higher the tension so the name just doesn't seem right. A great name for this quantity occurred to me suddenly: "Slack"! The desired length of the four cables in a tetra, added up, divided by the sum of the length of the two bars crossing in the middle is now called slack. I've loved the word slack ever since I came across The Church of the Subgenius. This version has a slider for you to raise or lower the slack, and I recommend you play around with it, probably best with zero-gravity.

Technorati Tags: evolution tensegrity architecture

Another fascinating friday spent talking and coding from a place overlooking the city. It was such a beautiful bright day in Rotterdam I took a picture with my laptop.

Much of the morning was spent talking and exchanging geometrical and architectural ideas with Hans Moor, although It's clear that we're approaching these ideas of evolution from very different points of view.

He doesn't really work with numbers or math, and that kind of things is essential for me to do what I need to do. He thinks about how people will experience the spaces, and how the structure can be made flexible and use space to give people impressions. I'm sure I'll get to that at some point later on, but for now I'm still wrestling with a number of fundamental issues in arriving at a growable tensegrity geometry.

My bottom-up orientation and my concentration on the purity of the mathematical model and the efficiency of the calculations (I need to accelerate time as much as possible!) are far removed from his considerations about how people experience architectural structures. We seem to be building a quite unique bridge between two different worlds, and somehow we both have the intuition that it's going to result in something.

Hans and I talked a lot about the idea of "Intelligent Design", and how the aesthetic of the architecture that might arise from this kind of evolution process is to be found in the economy of the result. We want a kind of fitness function that takes several different aspects into account at the same time, and one of the most important ones is economy! The beauty is in the economy.

It's quite funny because I try and convince Hans that the fitness function will be unable to fully capture what we want these things to become and that his architect intuitions will be needed as a steering force in the selection. This is what I want to call "Intelligent Design", fully aware that this amounts to intentionally co-opting the term from the religious folks. He seems to think that the human role can disappear completely because of that very thing: the beauty is in the economy. It's like we're arguing each others' points.

Diving back into the code after lunch, I tried to explain to Hans what I had been building through the week. My drive is to find just the right ways to reduce degrees of freedom. There are going to be numbers involved, but anything I can do to reduce the number of differnt numbers makes the result that much easier to handle. One main consideration is to create a scenario where no floating-point numbers have to come in from the. The genes will be talking in discrete terms, not in continous terms.

A couple of opportunities for reducing degrees of freedom have convinced me that the direction I took last week fortunately still seems like a good direction, having the Tetra play a central role. Not everyone agrees yet.

In response to last week, David Weston sent me an email with an interesting proposal, pointing to a beautiful video on youtube that I hadn't seen: "I was recently alerted to this tensegrity video on YouTube that shows the construction of a buckyball (truncated icosahedron?) using 30 bows (sticks with thread attached at each end). This video suggests that the basic building block for tensegrity structures is a bow." I've been thinking in terms of the "bow" for a long time, but I no longer think it should be considered central.

I've developed the Tetra idea further to reduce degrees of freedom, giving it a "tension factor" and a "pull vector". The tension factor is the total of the desired lengths of all four cables, divided by the total length of the two bars. The nice thing about this tension factor is that it is independent of size, since it expresses something relative and local to the tetra. The pull vector was also designed to express something relative as well: the different desired lengths of the four cables. The pull vector determines what you might call "the shape of the kite".

You will remember that the tetra is flat if it is not entwined with other ones into a tensegrity, and in this state its bars are crossed. The best image for this is a kite, and a square kite would have a pull vector of ( 1/4, 1/4, 1/4, 1/4 ). Notice that the pull vector is four numbers and it expresses the relative lengths, the total of all four numbers being 1.

Imagine a kite with this pull vector: ( 1/16, 1/4, 15/16, 1/4 ). That would be a kite that is very lopsided, with one very short side. This is the kind of tetra we often see in tensegrities.

So the tension factor and the pull vector can say a lot about the shape of a tetra, and if all tetras in a tensegrity share these values then they determine global features of the tensegrity. That's the way I've implemented to start off. One more thing is that a tetra can have its pull vector shifted around so that a different cable becomes the shortest, so each tetra has a pullVectorOffset with values 0, 1, 2, or 3. I guess it could be flipped too, but I'm leaving that for now.

After I got this all working I started thinking hard again about how to grow tensegrities. If this tetra is the building block then I should be able to just keep adding tetras joining new bars to existing bars. Unfortunately it doesn't quite work that way, unless I come up with some really interesting ways for tetras to kind of "give way" to others because when so many inter-bar tetras are added the tensegrity has just too many cables active. Somehow certain cables should decide not to be active, or something.

Meanwhile, when I showed Hans the basic three-bar tensegrity module wobbling and bouncing around he finds the thing beautiful in its simplicity. Every still-weird tensegrity that I build bigger than that one he finds kind of confusing and ugly. These are useful morsels of input, and exactly the reason I wanted to get involved with architects.

I went and just sat down for a while to think it all through, because I felt paralyzed by not knowing what the next step should be. It didn't look like I could get a tensegrity growing from scratch by just connecting new things to it. Somehow a tensegrity is a "whole" and you can't just think of it in terms of elements, but at the same time I really want this to be a bottom-up evolution of elements. The tetras will have to interconnect, perhaps communicate via their shared bars, and figure out who gets priority and who relaxes their cables, or something. It was kind of like "writers' block". I was sitting there looking at the Maas River and the Erasmus bridge, and I was stuck. Was David Weston's video really suggesting that the bow is central? I couldn't prove it for myself either way.

Then it hit me. This is a feeling I remember from earlier Darwin at Home work. Sometimes it's impossible to imagine how things can be made to "grow" when you don't yet have something working already, almost chicken-and-egg. These 3D tensegrities are almost impossible to draw on 2D paper so it's extremely challenging to think it all through. The intuitions about how to proceed are nowhere to be found! I need to build up the intuition much more: mine, Hans', and people following this development.

I decided that what I need to have is the tools to be able to build tensegrities by hand before I'll be able to understand how to make them grow. Even if the tensegrites initially consist of repeated elements I'm sure that it would be enough to get the mental juices flowing in the right way. So I started programming the things needed to be able to build tensegrities by hand from this basic module. Since modules cannot connect with bars against bars, I had to make the cables such that they are ready to accept connections with bars. Every cable now gets a "middle joint" which is not yet connected to a bar, but it is ready to do just that on command. Here's a screen shot so you can see all the candidate connection points:

I plan to set up the rest of the interaction this week to make building possible and publish a new version on the web so you all can play with it a bit. Imagine the balls halfway the cables in the image above to be "attractive" to the bar ends of a nearby module. This is how they will connect up, like blocks. Each connection is a triangle of bar-end to cable connections.

• Cable.java - Cables now have a middle joint.
• Tensegrity.java - creates and maintains the middles

Technorati Tags: evolution tensegrity darwin

It's great to be back in business with Darwin at Home! Thanks to the people who sent me feedback after the most recent episode, because it's really encouraging.

Last night I spent more than an hour chatting with a few other people on a live call-in internet radio show about artificial life hosted by the ever-gracious Tom Barbalet and available in podcast form if you feel inclined to listen to that kind of discussion. I thought it was a fascinating talk!

This friday I spent my first full day working on Darwin at Home at the architect's office where Hans Moor works, and it was inspiring to write code with such an incredible view of the city of Rotterdam. The most fascinating part of the day was when we had lunch, and I was surrounded by four architects asking questions about evolution and listening to my anecdotes about getting surprised by what survival of the fittest discovered inside my computer. They were very interested in what I had to say and wanted to see more of it in the form of a presentation, with lots of question-answer time.

The most difficult thing to explain was that I need to have the main thinking of the algorithm happen at the very low level, creating a bottom-up emergent organization instead of some kind of top-down design approach.

Code-wise it was also a very interesting day of challenges, because it was one of those days when you learn a great deal by discovering that you were on a dead-end street. In my case on friday it involved making the next step after the BarJoint that I have talked about in previous shows. When you connect two tensegrities together to make a new one, you inevitably bring bar ends in contact with cables, so I built some code to handle this splitting of a cable into two cables of half the span and connecting the ends properly. But then I imagined splitting one of the halves up again and realized that I needed the idea of a "cable chain" which would be able to split up into any number of cables, punctuated by joints where bars impinge.

As it turns out this is a useless concept and I've removed it from the code already. On top of that, I'm now having my doubts about the relevance of the BarJoint, but I'll hold on to that a bit longer.

But the real insight came after hitting the brick wall and then wondering what could actually be the right way to approach the problem. The brick wall was that the tension in a tensegrity just forms a network, so any idea of a "chain" of cables is never enough. Only with endless overlapping chains would the whole network be captured, and they really don't have any use then.

The insight is a little hard to describe, but it's really about what element can be the focus of behavior. There are bars and cables, and so far I've been considering bars to be the location of behavior. But the more you think about what a bar experiences and how it might interpret its experiences, the more you realize that it's not the right "atom" of structure for behavior. The "atom" must contain both bars and cables!

The answer is: the Tetra. That is, the tetrahedron consisting of two bars and the four cables connecting their ends into a kind of "kite" shape. The bars cross and the cables stretch around them. But the shape is not square and the bars should not actually cross. In this episode I try to explain this.

• Tetra.java - the new "atom" of behavior
• Volume.java - visit tetras, calculate volume

Technorati Tags: tensegrity evolution darwin architecture