 |
Physical WorldVideos |
|
|
|
| |
Note: This project has been superseeded by the Mechasphere project as of 11/18/2004.
Last updated 10/17/2004
If you're curious about the performance of the system, I find that the speed you are likely to see the animations running (unless you see occasional delays) is pretty fast. It's about twice as fast as I see the actual programs running on my PC. And that's even though only one frame is saved for the animation per five frames I see at runtime.
Whirlpool
H2O
Tangle
Bumpers
Finite State Machine
XML Modelling
Sample Frames (click any to see full size)
Here's a fairly simple world. In it are the following components:
When you see the animation, it should become clear why I called it "Whirlpool". The vortex drives the particles to slowly circulate round and round.
H2O
Watch the Video
(a long-running animated GIF)
Sample Frames (click any to see full size)
This is a world that demonstrates all of the basic elements of the "world" layer. It is composed of:
This is a rich demonstration and fun to watch. Although I didn't intend it, the three particles tied together look like a cartoonish little fellow zipping about. The various forces conspire nicely to jostle the thing about. I particularly like how the uniform planar force field pulling particles downward is counterbalanced as the particles near the bottom by the distance-varying upward pushing force field that has its centerline just below where the screen ends. The effect creates a sort of buoyancy elevation for particles based on their masses, just like a submarine in water has its buoyancy point (assuming no changes in ballast). It's centered below the bottom because I didn't want the free particles to experience a nearly infinite force field at the bottom.
It's also fun to see the interaction of the gravity-like radial force that pulls things toward the center of the "lollipop", with force varying with distance, and the vortex around it. The particle group seems almost to be trying to climb up the black ball because of this combination.
As you might have guessed, I chose the name "H2O" because the particles together look a little like a water molecule model.
Tangle
Watch the Video
(a long-running animated GIF)
Sample Frames (click any to see full size)
This represents a key departure from the previous demos in that it features components found in the "robotics" layer, above the "world" layer. In this case, it's in the form of "thrusters". These are particles with two additional features: the ability to store energy and the ability to consume that energy and provide directed thrust. You'll see this represented as the thick red lines emanating from the top particles on each of the "rockets" in this demo. The planet in this demo is composed of five copies of:
As you watch the rockets, take note that some have longer red lines. The longer the red lines are, the stronger the thrust and the faster they run out of energy. A thruster is defined in part by reference to another particle that points in the direction the thrust tends to push towards. In this case, however, the opposite is true. The thrust is pushing away from the steering particles (in the "feet"), but only because the thrust for each rocket has a negative magnitude. Thruster particles are allowed to have positive or negative thrust.
I especially like how realistic the physics of all this appears. Each rocket starts out at rest and begins by fighting off the "gravity" pulling them down. As they collide, things get quite interesting. The only part that seems confusing at first is how some of the rockets seem to pass through each other. This is because the links (light blue lines) don't have any physical substance in this world like the particles do. They don't interact with anything except the particles at either of their ends. I learned long ago that the mathematics involved in dealing with planar interactions is much more processor-intensive than for circles (and spheres); hence the world not being made of polygons. I decided early on that environmental richness and ease of interpretation to the human eye are more important than fidelity in fine detail to the physical world we're familiar with. Such "problems" generally aren't worth "fixing" because the cost is outweighed by the gains in simplicity and execution speed.
By the way, technically speaking, the Thruster class is derived from the ActiveParticle class, derived in turn from the Particle base class. ActiveParticle is not intended to be instantiated by itself, but be a base for most other particles created for the robotics layer. ActiveParticle has special properties, like the .InputData collection and .EnergyLevel that are used by other components for communication, energy transfer, and other such features required by robotics components.
Bumpers
Watch the Video
(a long-running animated GIF)
Sample Frames (click any to see full size)
This is a little demo I made to test and illustrate the Bumper class, derived from the ActiveParticle class. It is essentially an accelerometer that registers any jolt, with the sensitivity of each bumper to jolts controlled by the application.
The planet in this demo is composed of:
This is also a departure from the earlier videos in that it illustrates a neat feature of the viewer. The user can use the mouse to grab a particle and drag it around. In this video, you see me using the purple particle like an air hockey paddle to bump around the two bumper particles.
Watch as the bumpers are hit how their centers light up in red, indicating their .Excitement levels. The harder the bump, the brighter the lighting. The larger bumper's .Sensitivity property is about 100 times higher than the smaller one's, so you'll notice it lights up with even the slightest force applied to it by the paddle, walls, other bumper, and even air friction.
Notice also how the .Excitement level, indicated by the red light, slowly fades after a jolt. That's to mimic a similar facet of how neurons appear to work. That is, neurons seem to have slowly degrading firing responses when triggered, rather than having fixed clock steps like most modern computers do. I think of it as a sort of "working memory" that allows delays in the brain as signals propagate to be compensated for. In a typical desktop computer's CPU chip, this is irrelevant because the unit of time available for each operation is generally no shorter than the time it takes for signals to propagate from any one part of the chip to any another.
Finite State Machine
Watch the Video
(a long-running animated GIF)
Sample Frames (click any to see full size)
This video demonstrates simple machines with the first kind of decision-making particle type: the finite state machine (FSM). This completes the basic loop required for a first draft of the robotics layer. You see here critters composed of sensors (bumpers), motors (thrusters), and decision-makers.
An FSM has a set of input bits. For each of all finite possible combination of those input bit values, there is a corresponding "combination". There is a defined set of outputs, and each input combination sets these values.
I should note that I changed the way the bumpers worked. Because these machines tend to "jiggle" a lot from the combined forces and because time is chopped up into discrete units, once a critter like these gets going, I found the bumpers were constantly excited by all the jostling. So instead, I modified the bumpers to only fire when they touch something else; namely, another particle, a barrier, or a wall. The amount of force with which it strikes the other object determines the excitement level. Note that in the video, the bumpers have a sort of halo around them with a sort of "crosshairs" and that the bumpers don't get excited until only the inner circle representing the particle's actual radius actually touches something. The halo and crosshairs are just decoration for bumpers.
In this experiment, each critter has two bumpers (initially, the top two particles), two thrusters (initially, the bottom two), and one FSM particle (center). The FSM is wired to accept the bumpers' excitement levels as input. Each input bit is mapped to the output of some other device and will have a value of zero or one based on whether it reaches or exceeds a threshold value set for each input bit. For each combination of input bit values, there is a corresponding set of output values. These are floating point numbers, though, and not binary values. The pattern here is pretty simple, and can be summarized as follows:
| In: Left Bumper | In: Right Bumper | Out: Left Thruster | Out: Right Thruster |
|---|---|---|---|
| < 0.9 (not touching) | < 0.9 (not touching) | 0.5 (forward) | 0.5 (forward) |
| < 0.9 (not touching) | >= 0.9 (touching) | 0.5 (forward) | -1 (backward) |
| >= 0.9 (touching) | < 0.9 (not touching) | -1 (backward) | 0.5 (forward) |
| >= 0.9 (touching) | >= 0.9 (touching) | -1 (backward) | -2 (backward) |
It's worth noting that I don't think there's a lot of value to be gained in scaling up this sort of experiment to use ever more complicated finite state machines, because they grow very quickly in design complexity and can be hard for most people to wrap their brains around when there are large tables. Keep in mind that for each input bit you add, the number of possible input combinations gets doubled. That is, the number of combinations is 2 ^ N, where N is the number of input bits. So adding bits successively gives you 2, 4, 8, 16, 32, 64, and so on, up to 4B combinations for just 32 bits. Yes, one can split logic up into separate FSMs and so divide and conquer the thinking, but the results are not likely to be much better.
To be sure, I mainly chose to make an FSM as a starting point to vet out some of my design decisions, and it's proved a good thing. It showed me the flaw in my assumptions about the bumper particle, for instance. It also forced me to rethink how I interconnect the various information components
XML Modelling
Watch the Video
(a long-running animated GIF)
Sample Frames (click any to see full size)
My latest major addition is support for XML files to define a planet. One can set the size of the planet, plant various effects (force fields, barriers, and fixed-position particles), define segments of multiple particles, and place instances of bodies composed of replicated segments.
I'm particularly excited by this addition, because for me it broke the complexity barrier I was running into by hard-coding critters. Segments can be instantiated and inherited from other defined segments with modifications. This breaking down of critters into segments within segments with inner replication, in addition to the ability to rotate and relatively place segments, make it almost trivial to design critters of rich complexity with little effort, compared to the alternative. Having it all in an XML file constrains what can be done in definition, but surely makes it easy. And it means I can just hit the "Restart" button after modifying the XML file, rather than recompiling and restarting the program after making code changes.
At the time of this writing, I had successfully implemented basic support for constructing all of the types of particles and most of the miscellaneous effects possible, but not for the brain components. I didn't see that as prerequisite, since this project is about a physical world. The brain components included with the project are just icing.
 |
Produced in cooperation with Carnell Information Systems, Inc. |