Mon, 31 Mar 2008
Last thursday I finally gave the presentation about D@H and especially my latest Project Tensegrity efforts to a group of architects, civil engineers, academics, real estate developers and others. It's about 45 minutes long, so if you have the patience, just click on the picture here and you will jump over to Google Video to watch it.
Technorati Tags: tensegrity evolution darwin architecture
Tue, 25 Mar 2008
Tonight is a get-together of the Greythumb artificial life group in London, and Justin Lyon and I are trying to set up so that I am able to appear via Skype Video or iChat screen sharing to demonstrate the stuff I'm working on these days.
What I woud like to show people is the Tensegrity Laboratory that I've built in order to acquire enough intuition about how Tensegrity works so that I can create an appropriate growth algorithm. This is a link to the program that I hope to demonstrate remotely tonight:
http://www.darwinathome.org/tensegrity-20080325/
The processes so far involve:
It's interesting to think about this in the context of the ideas that have been floating around the Biota Podcast about evolving instruction sets for really open-ended evolution.
The main difference between that kind of thing and my work is that I'm focused on 3d space and how to evolve structures that can actually one day be built. The domain here is very specific, so the steps described above make up an "instruction set" for building tensegrities.
Wed, 12 Mar 2008
First things first. I decided this week to "reboot the world" on the Intelligent Design version of Darwin at Home so that we can once again start from scratch and see new kinds of bodies emerge. If anybody is interested in data-mining, I have a huge archive file with all the XML representation of the different creatures everywhere as they've evolved through the last months. I can imagine that this might be interesting to academics. Let me know if you want it.
Then on to the recent developments. I found myself dividing the tensegrity program into two parts: one of them is a "laboratory" where we have lots of interesting controls to play with, and the other is a "world" where growth and sprouting is starting to happen autonomously and you can travel around a huge space, creating them and watching them grow. It's all in the beginning stages, but both versions have been wrapped into one and put online for you to play with.
Listen to the podcast to hear about tensegrity vulcanization, whereby extra cables are added to stiffen things up.
http://www.darwinathome.org/tensegrity-20080312/
I've been working on this for quite a while, nowadays spending the odd day at the architects' office, and I'm afraid it's difficult for me to leave it alone during evenings and weekends as well. It's so much fun to play around with these tensegrity things and to puzzle out how they actually work. Also, it's good to get the navigation working nicely. What's really encouraging as well is how the architects react when I show them what's developing, because they're very enthusiastic.
Most of the efforts in the last while have been to make sure that it's possible for these tensegrities to kind of grow on their own. To make this happen, I've created classes called Module and Triangle (links below) to represent segments of the tensegrities and the places where new ones can sprout, respectively. A module is capable of sniffing out what triangles it currently has.
To set up something for starters so that tensegrities can grow spontaneously in the "world" version, I've set up a new Life package with mostly Java interfaces that give a carefully limited view of the things that can be manipulated. For example, the "Segment" is implemented by the Module.java below. I'll talk more about these things as they start to take a more concrete form.
By the way, this podcast and the last were recorded using a very tiny and effective device, the iAudio U3. I love the convenience of just using such a little device with no moving parts, and I like the quality enough to keep using it for this.
Technorati Tags: evolution tensegrity darwin
Sun, 2 Mar 2008
We took a little break in the form of a trip to Berlin last week, but when I arrived on friday I thought it might be fun to set the alarm and take part in the Biota Live Podcast from the place we rented, since there was WiFi.
As usual it was a great discussion and it got me thinking a lot more about making something you might call artificial life. In this podcast episode I try and describe the vision of tensegrities as plants, primarily busy with seeding themselves.
This should all be possible to do, and I'm not sure that I can resist trying now that the image is lodged in my mind.
Technorati Tags: evolution tensegrity darwin
Sun, 17 Feb 2008
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
Sun, 10 Feb 2008
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.
Technorati Tags: evolution tensegrity darwin
Sun, 3 Feb 2008
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.
Technorati Tags: tensegrity evolution darwin architecture
Sun, 20 Jan 2008
Things are changing for me and for Darwin at Home. From february onwards I will be back into the contracting business, which will probably give me a lot more time to work on Darwin at Home.
The plan is to do something interesting and different very soon. My architect friend Hans Moor has agreed to let me work at his office for at least one day a week for a while. No more stealing evenings and weekends, but instead I'll be spending whole days working on this project!
In this podcast I talk about all of this and what Hans and I hope to accomplish together. I'm looking to find out whether Darwin at Home might be able to evolve something that is meaningful in the world of architecture.
Technorati Tags: architecture evolution java
Sun, 18 Nov 2007
In this episode of the podcast I talk about a nice approach to a genetic code for the system, not based on bytes but right down to the bits. It's all about ones and zeros in computers, so this is the level of our genetic instructions.
We can always draw a binary tree where each node has two subnodes, except for the leaves of the tree. Then every bit we read from the gene can make us step left or right as we ascend the tree to reach a leaf. When we reach a leaf, we shout the word that's "written on it". Problem with this approach is that one bit flip changes the meaning of everything that follows.
Instead we go for a delimiter approach where 00 becomes a delimiter. Then you can look at a string of bits as a string of words separated by pairs of zeroes. So this string of bits 001010010101010011100110101101 becomes 00 101 00 1010101 00 111 00 110101101. remove the delimiters and you get the words: { "","101","1010101","111","110101101" }.
The number of possible words of length N is the the (N+1)th Fibonacci number. The Fib sequence is 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89,... where each number is the sum of the two that preceded it.
Not only that, but the frequencies of the different words are very divergent. Long words are rare, of course.
Somehow these words have to come to "mean something" to the elements of the tensegrity which are growing during the embryology phase. Perhaps some infrequent words would mean "replicate" and some frequent words would mean "grow" or "connect". Play with the binary code and the delimiters and let me know what you think.
Technorati Tags: evolution tensegrity binary genes fibonacci
Sun, 11 Nov 2007
There's a new version of the Tensegrity Application online for you to take a look at. You will notice that there's text at the top describing how long the bars are, and if you watch you will see that every new tensegrity that appears is smaller than the previous one. The nice effect of getting smaller is that the cable forces really start to dominate eventually, while they are relatively weak in the beginning. Think about this.
I've been busy building a rendering where the bars appear to be substantial things, shaped a bit like cigars, while the cables are still appearing as blue lines. To do this and keep things flexible I've taken the bar and cable painters out of the view class, and made them separate little classes. Below you will find links to the SphereBarPainter and the LineCablePainter.
Also, while setting up the visualization of the new tensegrity triangle unit from last time (three bar tensegrity) it became clear that we need a good way to maintain the camera position. For this I created a class Vehicle, the source of which is also linked below. The Vehicle takes the PointOfView and manipulates it during every tick of the clock, trying to move it towards focusing on an ideal focus location and maintain an ideal distance from that focus. In the view class, all we have to do is call its "adjust" method and it will push the PointOfView one more step in the right direction.
You should be able to see the results of this in how you find yourself following the tensegrity as it bounces around in the new version online. You will also see the lovely three-bar tensegrity that is created by the little factory method from last time.
I'm afraid I've also been doing quite a bit of tweaking to figure out how to make the gravity and the floor work in an good-looking way. Here is the relevant code from Physics.java if you're interested:
float downward = gravity*mass;
float localDrag = joint.velocity.quadrance() * drag;
float damping = DAMPING;
float height = joint.location.z;
if (height < BUFFER_ZONE) {
float antigravity = downward * ANTIGRAVITY_FACTOR;
float highDamping = damping * DAMPING_FACTOR;
float killXY;
if (height > -BUFFER_ZONE) {
// 1 at top, 0 at bottom
float above = (height + BUFFER_ZONE)/(BUFFER_ZONE*2);
// 0 at top, 1 at bottom
float below = (BUFFER_ZONE - height)/(BUFFER_ZONE*2);
downward = downward * above + antigravity * below;
damping = damping * above + highDamping * below;
killXY = above;
}
else {
downward = antigravity;
damping = highDamping;
killXY = 0;
}
momentum.x *= killXY;
momentum.y *= killXY;
}
momentum.z -= downward;
momentum.scale(1 - localDrag);
momentum.scale(1 - damping);
.....
As you can see I've added in damping (just reduces momentum, regardless of velocity) and also added functionality to kill the X and Y momentum when a joint goes below the floor (anti-slipperiness). Other than that, the gravity gradually gives in to the antigravity the further down you are. It's fun to play around with physics, but I realize that I will eventually have to settle on a physics strategy that I can defend well.
In this episode of the podcast I talk about this stuff, and I read a little section of Bucky Fuller's book "Synergetics 2". I received this book in the mail from the man who co-authored it with Fuller himself Ed Applewhite with the inscription "For Gerald de Jong - in gratitude for his imaginative amplification of Fuller's ideas as found in this work".
Tue, 6 Nov 2007
What is mass? For the purposes of this program we need not have something that is exactly replicates the real world physics, but it has to be a correct analogy given the assumptions behind the project. A while ago I mentioned that we are assuming that the tension cables are effectively weightless, so our only concern is the bars when we talk about mass. Now if a real world bar of span S has a particular mass value M (related to the number of atoms), then how much mass would a bar twice as long have? The number of atoms does not double, but instead the whole bar has to get longer and thicker at the same time. Length, width, and height have to double, which means that the double-length bar has 2 * 2 * 2 = 8 times us much mass (as many atoms). So a function has been added to Bar.java:
public float getMass() {
return span*span*span;
}
As you can see, there are no units here. No centimeters or grams. Why? Because this program is analogous to physical reality, but not a copy. Clearly a doubling causes a multiplication by eight, so we're good with respect to increasing and decreasing. The nice thing is that this is all we need.
Now, what does mass actually do? For that we have to visit Physics.java again. First, mass affects the amount of force downwards that gravity has on objects. So a bar twice as long will be pulled downwards eight times as hard. Another effect that gravity has in the real world is that it affects how much a standing object wants to stand still, or how much a moving object wants to keep moving. Inertia is directly related to mass. Momentum is the word used to describe the velocity times the mass of an object. It's momentum that is conserved when one billiard ball bounces against another. Force is defined as a change of momentum relative to time. We need momentum.
So now in the Physics class, the move method works with momentum by setting the momentum arrow to the velocity arrow, scaled by the mass. It's the momentum upon which the forces act. When all of the forces have done their work, the new momentum is scaled down by mass to set the velocity.
In this episode 25 of the podcast, I talk about mass and how it affects the physics, as well as this lovely gem:
public Tensegrity createThreeBar() {
Tensegrity t = new Tensegrity();
Bar b0 = t.createBar(
new Arrow(ZERO, ZERO, ZERO),
new Arrow(ZERO, ZERO, ONE),
ONE
);
Bar b1 = t.createBar(
new Arrow(-HALF, ZERO, HALF),
new Arrow(HALF, ZERO, HALF),
ONE
);
Bar b2 = t.createBar(
new Arrow(ZERO, -HALF, HALF),
new Arrow(ZERO, HALF, HALF),
ONE
);
t.createBarJoint(b2,b0.alpha);
t.createBarJoint(b1,b0.omega);
t.createBarJoint(b0,b1.alpha);
t.createBarJoint(b2,b1.omega);
t.createBarJoint(b0,b2.alpha);
t.createBarJoint(b1,b2.omega);
return t;
}
Technorati Tags: evolution tensegrity java darwin
Sun, 21 Oct 2007
Why is it so interesting to create a sytem like this from scratch with so few basic assumptions (read: so little code)?
All the evolution code in Darwin at Home has so far been based on Elastic Interval Geometry which works with structures made of springs. The definition of a spring involves both pushing and pulling depending on whether the spring is shorter or longer than it wants to be.. it's default span. There was enough of a focus on tetrahedra and octahedra and the growth process was careful enough that there were rarely intervals that cross each other. They were programmed to grow in ways that didn't result in curling up inside themselves, but it could still happen and if it happened crossing went undetected.
Any tensegrity growth algorithm looks like it will involve lots of crossings of bars and cables in its intermediate phases (when a new element appears) and since crossings are not permitted in real life there will have to be a way of having the offending bars and cables somehow evaporate. It's easy to do that, but it will be a challenge to have it work in ways that can evolve, hopefully discovering some kind of strategy through natural selection.
Another major departure from previous Darwin at Home work will be that these tensegrity bodies will not be evolved in their "adult form". Until now I've been having mutated peers compete and passing from generation to generation was a question of body copying followed by a tiny mutation. The evolution of tensegrities will be very different because bodies will have to start from scratch every generation and grow before they compete. Think of it as a kind of larva phase which has to proceed correctly in order for the adult tensegrity to become a successful contender. Hey and this process could even happen in a state of "altered physics" where, for example, the viscosity could be increased, preventing wild jittering as the cables "harden".
But this is still "future music" as we would say in Dutch. For now some difficult groundwork has to be done to deal with this new thing we have to be able to measure: Proximity. In this podcast episode 24, I try to explain in the clearest possible way what the math is behind the proximity of intervals (bars, cables), and how the software approach involves ghost objects called Cross which we don't see, but which persist as long as there is a danger of two intervals crossing. Also interesting is the Proximity class and how it does the Cross calculations, and why this visitor construction is the best way to implement proximity calculation.
Technorati Tags: evolution tensegrity java darwin code
Tue, 16 Oct 2007
While thinking and playing around to see if I could figure out some way to implement tensegrity growth, I realized that there were some important regularities in tensegrities that I was missing. I stared for a long time at Ken Snelson's Needle Tower and started to see what was a recurring pattern. Of course, the great Ken Snelson knew this kind of thing decades ago, and probably spent lots of time climbing around huge tensegrities and feeling them around him while building them. I don't get that opportunity, so my discoveries (if you call them that) are about how to formulate it all in software so we can vastly accelerate time and evolve virtual tensegrities.
The regularity that struck me was a triangle that you often see connecting the joint at the end of one bar to both ends of another bar. Most cables are involved in such a relationship, so I decided to formalize that by creating a class called BarJoint which holds a Bar, a Joint, and the two Cables that connect them into a triangle. Why bother? Well..
There's a simplification available in there! (Also, there's an opportunity to create a phenotypical attribute that is easily expressed, which will help with genetics later). A BarJoint can be used to ensure that the two cables' spans add up to the bar's span, or a little less. The point is, the cables' spans are derived quantities, so their spans are no longer "data". Instead we can just talk about the proportion of the total span the cables each have. One number for two cables. It may be difficult for you to imagine how important this is for us, but it should eventually become clear. An appreciation for this reduction of information is what you need when you're approaching design genetically.
One key thing is that most of the cables in tensegrities are involved in such triangles, and since there are lots more cables than bars, this takes a big chunk out of the number of numbers that will represent a tensegrity (genetically, if you will). Also, since I'm thinking in terms of having the bars contain the "genes", it has been set up so that the bars hold references to the BarJoints that they are involved with. Bars will eventually manipulate the proportion number I mention above for their associated BarJoints.
You can see the first true tensegrity (six bars that don't cross) bounce around here: http://www.darwinathome.org/tensegrity-20071016/. Every cable in this tensegrity is part of a BarJoint. That won't be the case when we build tensegrity columns like Snelson's Needle tower, since there are extra cables between the "modules".
Technorati Tags: evolution tensegrity java darwin code
Sat, 6 Oct 2007
You know, in some ways making software must be like making a work of art, because I find that my emotions are somehow tied to the thing I'm working on, especially this project. When it's working well and improving I get happy, but there's a palpable down feeling when it's not working. Sometimes stepping through code with a debugger feels like punishment for having been stupid. I guess it shouldn't but...
By the way, I had some fun with my green laser and long exposure picture. That's me!
Once the tensegrity was viewable it became abundantly clear that I had made some big mistakes in the physics calculations. Now that they're working beautifully I'm feeling really good. Getting from there to here was a bit of a struggle, and building software is much more humbling than most people realize because you get exactly the behavior that you program and nobody writes perfect code first time. You always have to look back and pity the previous version of yourself who wrote that stupid code. Funny.
The first problem was the hopeful idea I had to remove "slack" from the whole tensegrity thing and have cables pull proportionally to their length. That turns out to be dead wrong, and no good tensegrities can be built that way. I watched them slip out of shape and fall flat a number of times, and then it was clear that cables need to be more intense about their lengths. They have to pull hard when they're just a bit too long. So the first refactor was to move the "span" number back into the superclass Interval of Bar and Cable so that both entities have spans again.
The second problem was that the Joint actually has to have more than just two arrows: position and movement. To do quadratic drag there must be a velocity arrow, and to handle the bar physics there has to be another arrow to separate all the calculations related to cables, which I have called cableForce. This allows the physics to let all the cable forces on a joint accumulate, do the calculations with them, and only later apply the resulting force to the velocity of the joints. The cancelling of the opposing forces in a Bar that I described a little while ago must happen separately like this for it to work. Then the velocity can just be diminished according to its quadrance (the square of it's length or distance).
So the Joint class now holds three arrows. It's position, velocity, and an extra arrow to hold the cable forces that accumulate, cancel out, are applied to velocity, and then zapped back to zero during every tick of the clock (every call to step() in the Physics class).
Which brings me to Physics, which I had to largely rewrite because it had to work very differently. This is what I talk about mostly in the podcast. I'm amazed at how wrong it was, and happy that it has now become clearer and simpler at the same time as becoming "correct". The coolest thing of all is that the floor is now not solid but somewhat fluffy instead, just as listener Matt Dick suggested. It's even pluggable using the ResurfacingStrategy interface.
The updated version is available using Java Web Start from http://www.darwinathome.org/tensegrity-20071006/
Technorati Tags: evolution tensegrity java darwin
Sun, 30 Sep 2007
I can assure you that this software is not going to end up looking like your average two hundred person-year game with its artistic teams and software teams. That being said, you never know what it might turn out looking like, because there are two ways that I might be able to adopt a sophisticated graphical front-end: Breve and Digital Space are kind of fellow-projects with this one related to www.biota.org and in the biota podcast series there has been some talk about collaboration.
It would be a real kick to introduce the graceful fluidity of tensegrity to those environments, and that might inspire future engineers to look into building things using tensegrity. At the very least it should be considered as a structural principle very useful in zero-gravity. I imagine the rotating wheel shape from 2001 A Space Odyessey but then not as a solid donut but rather as a vastly larger donut-shaped tensegrity where people live in the bars. Maybe there would even be bars that were bars that you could frequent.
For now, I'm impatient to have something to look at, and I want an animated view that performs at a really high rate of speed so the first thing to build will be a rendering based on lines instead of polygons. It's important not to forget that the most exciting thing that will happen with this software will be the evolution process, and that occurs out of anybody's view because observing the movement slows it down by orders of magnitude. When you view it, it should be possible to really make the movement fluid with a large frame rate.
Something I should mention: I had a text chat with Rui Alao last night, an internet friend and podcast listener from Brazil, who recently presented Darwin at Home at an academic conference, it seems. It was more about the concept than about the techniques, he said. I hope to hear more from him about it and that he puts the presentation online, even if it is in Portuguese.
The GL code is of course built on the basis of the Visitor idea from last episode, and the visitors required will be looking at the bars and cables and painting lines on the screen. This part of the code is really another refinement of what I've used in previous versions of Fluidiom, and not something I'm doing for the first time. The nice thing about that is by now I really kind of know how it all fits together so I can explain it with some more confidence.
Almost forgot! The graphical version is available using Java Web Start from http://www.darwinathome.org/tensegrity-20070930/
Technorati Tags: opengl jogl tensegrity geometry
