The virtual world components allow the construction of animats and of environments for them to inhabit. The emphasis is on being able to model environments used in animal behavioral experiments. The main components are walls and various devices for the animat (virtual animal) to interact with - food and water dispensers, sounds and lights.
For each type of device there are corresponding sensors and effectors which can be incorporated in the animat.
|
Load trj1.ccm show camera view run the model |
This example shows a simple environment defined by a rectangular boundary wall with a couple of insertion sites and a square trajectory. There is a camera connected to one of the insertion sites, which receives information about where the various components are and is roughly equivalent to a video camera looking down from above. The camera has to be attached to some point in the environment just to indicate what it is pointing at - exactly where does not matter.
The animat in this case is very simple - just a SpatialLocation object on its own. In the environment there are four TrajectorySite components linked in a continuous loop. The animat is connected to one of them. When the workbench is run, it just follows this trajectory for the specified time. Each point has a pause and an onward speed associated with it, indicating how long the animat should stop on arrival, and how fast it should head for the next point. Although the connectors may be curved, the animat takes a straight line from one point to the next.
|
Load trj1a.ccm show camera view distance along path run the model |
This example is very similar to the preceding one, but with a path linerizer component added. It is attached to the trajectory, and receives position input from the spatial location component. Its output is a single value, the distance around the trajectory measured from its starting point.
|
Load trj2.ccm show camera view run the model |
This model has two trajectories with an InsertionSwitch to move the animat from one to the other in the course of an experiment. The spatial location object is connected to the switch, and then separate outputs of the switch go to each trajectory. The switch is operated by sending it an event with an index of zero or one. There are many ways to generate such events, but in the example it is done with two SpikeButtons connected to a concatenator. By default, each button generates events with index zero, but after going through the concatenator, the second comes out with index one, and so acts to switch the animat to the second trajectory.
To operate the buttons, put the workbench into run mode (three-quarters circle at the bottom right). In this state, only the components which can influence the running model are accessible. In particular, you can press each of the spike buttons to change trajectory.
|
Load trj3.ccm show sensor output show camera view run the model |
Here the environment has been extended with a lever and a couple of food dispensers. The animat has also been extended with a LeverPresser and an Ingester. Note that these act both as sensor and effector. The ports on the right export sensory information. The one on the left activates the effector. A concatenator is used to channel the output into a recorder which shows when the animat is within range of the devices.
The various components of the animat are connected with Cords. That is, they are physically tied together to indicate that the lever presser and ingester are in the same place as the SpatialLocation component, but no information travels between them. The vector output is used in this example, but most sensors also deliver a spiking output at a specified frequency when within range.
|
Load trj4.ccm show camera view show sensor output show device activation run the model |
The next thing to do is activate the effectors so they change the environment. This is done in the example simply by connecting the spiking output from each effector-sensor to its input. So, whenever the animat is within range it will perform the corresponding action - that is, it eats whatever it can, and presses whatever it can. The output from the devices is concatenated into a vector recorder which gets a spike each time a lever is pressed or the food is eaten.
The spike generator in the left sends occasional spikes to re-charge the dispensers. Normally this would be done in a more systematic manner with an EventSequence or perhaps even a Jython script.
|
Load trj5.ccm show camera view show sensor output run the model |
The workbench in the previous example is rather cluttered, so here the components have been grouped into Body and Chamber objects. This has the advantage that they can be stored and reused separately, and also enables the compilation process (when the model is converted to executable components) to run more efficiently.
But otherwise, everything runs just as before. Note, however that any object which interacts with the model or displays its progress must remain at the top level. This applies to the vector recorders and camera in this example. Putting them inside a component would generate errors when the model was run (Dec 01 - at least I think it would, though maybe this could be made to work...).