OpenAL does normally not allow for multiple listeners, hence - as previously described - the OpenAL implementation needed to be adapted so that this is allowed. Now multiple robots can be simulated in the same arena, each with a specific distance to a sound source and hearing that sound depending on the distance louder or weaker. To this implementation is now added a "delay" effect. Normal OpenAL (Soft) does already taking into account attenuation (the intensity of the signal depending on the distance), but a delay is a totally different beast. What we implemented is a simple trick that skips some samples if the delay we calculated - using the listener-source distance and the speed of sound - needs us to jump forwards in the audio stream (we are approaching the source), and adds some zeros in the audio stream if we depart from the source. This might lead to some artifacts but is already a perfect for the case of a static setup. The onset of the sounds is visualized in the following picture. You can see that the listener (at the bottom) who is further away does not only hear the sound with a reduced amplitude, but it also delayed for 0.2 "units".



You can find the code at [1] which is open-source, the same LGPL license as the original OpenAL Soft implementation. The next task is to adapt the (OpenCV) blob following software [2] for Android-enabled Mindstorm NXT robot so that it will be able to orient itself to audio sources. A movie showing that will follow soon!

[1] openal-sim
[2] mindopen

There are several internships in robotics available at our research company Almende. The company has been hosting PhD and MSc students and provides a challenging environment with sometimes even more liberty than at a university. One of the focus points of Almende is robotics. Many cheap robots ask for inherently distributed, scalable, and self-learning software, in the line of the research agenda of Almende, which concerns self-organization.

All activities described here are in the framework of the European project Replicator, this means you will need to be able to travel in Europe. In the Replicator project modular robots are built and programmed. Modular robots go beyond swarm robots in the sense that they can assemble to large robot organisms. As a research company we are not so much interested in direct applicability of the Replicator robots; we need first to address the fundamental problems that arise when we abstain from handcoding such robot organism shapes.

If you are pursuing a degree in computational biology, theoretical biology, systems biology, or bioinformatics, the following intership can be of interest. This one is defined by us and you will need to make a (or your) supervisor at the university enthousiastic. We will be happy to interact over emails to specify the technological and scientific importance of each internship.

Metamorphosis in self-organizing robots

In collaboration with the Vrije Universiteit in Amsterdam you will be exploring the evolution of sensors, their positions, their resolution, on the Replicator robot organisms.

Internship - Coevolution of Body and Sensors.pdf

In collaboration with the Radboud Universiteit Nijmegen you will be exploring a flexible control structure. Most robot control architectures are very rigid. Cognitive psychology, in this Koechlin, came up with a more flexible control structure, the meaning of which you will be able to explore in robotics.

Internship - Coping with Distractors.pdf (fulfilled)

Feel free to contact us.

YARP
A so-called iCub robot is shown at the right. The picture is a screenshot if the iCub simulator. The iCub is a robot mimicking a baby. It can stare at you and the full-fledged rolled out version is able to crawl and grasp objects. Its cognitive architecture uses components of global workspace theory, which is also under investigation at Almende for the Replicator robots. You can find some architecture pictures at the iCub wiki (and many scientific papers online). Quite interesting from an open-source perspective is that the iCub software is build on top of YARP. As formulated nicely by the designers in the paper Towards Long-Lived Robot Genes (pdf). I will quote ad verbatim (emphasis is mine):

With simulated robots it is extremely important to separate the controllers that operate on the simulated robots from the simulator software. If controllers by accident use simulator functionality, which might be as simple as an accidental call to an OpenCV library, this would mean that this library also need to exist on the robot itself. It is also important to provide exactly the same simulated device interface as a real device interface. Or even when the controller code is separated from the simulation code, it still needs to adapted to the real devices on the real robot. Last, but not least, by providing a network interface between devices (sensors, actuators) and controllers, it is very easy to implement distributed processing! All this is provided by YARP: Yet Another Robot Platform. A slightly misleading term, because there are not so many robot platforms that provide this much needed functionality!

Sending Images over YARP ports
YARP provide ports. A simulated device, in this case a camera, can send images over a YARP port. The yarpserver maintains a registry of all registered software modules. As soon as there is an interested party, for example the default available yarpview module. It is possible to connect the camera with the viewer on the command-line with something like: yarp connect /camera/front /view. At Almende we have developed something like this in the house, called the mbus. The smart thing of YARP is that it uses strings as port names (/camera/front in the example above) rather than integers. One of the things YARP cannot do is to startup processes remotely, but a wrapper for that is easily written. Actually, I stand corrected. Paul Fitzpatrick told me just now that there is a yarprun server, which is able to start and stop processes on a remote machine. This will likely be extremely valuable on modular robots!

YARP is lightweight, they don't support all OpenCV picture formats. They just support RGB and BGR without alpha channel. To be able to send images over YARP you have to convert the osg::Image to an IplImage (OpenCV). (Email me if you need this code.)

In the picture at the left, images are streamed over a YARP port. It shows the Symbricator3D simulator at the left. At the right you see a viewer, it shows what the robot is seeing through its front camera. The yarpserver in this case is running on another machine at our LAN. In the same way can controllers now be placed as separate binaries outsides of the Symbricator3D simulator. Nice, little blobs of code, easy to be reused in many research projects!

Glider
There have been some posts before about the gene regulatory network engine that is developed at Almende. This post shows one of the results of the integration of this engine with the 3D robot simulator, Symbricator3D, in the FP7 Replicator project.
Each robot runs the same gene regulatory network. The movie shows only the result of the evolutionary process. In the evolutionary process itself groups of robots compete with other groups of robots. The group of robots with the right gene regulatory network does have a fitness advantage compared to the other group. In total 32 groups of robots have been competing to create a so-called glider. A glider is a repeating pattern that can be found in cellular automata. It is a pattern of 5 units. By applying the local neighbour rules of the Game of Life it moves diagonally over the 2D grid. This can be seen in the picture at the left from wikipedia.

Metamorphosis
Although it might seem far fetched on first sight, a glider is a very special type of "organism". Its "body shape" changes continuously over time. Most of the research with respect to gene regulatory networks is tailored to development. The creation of a static body layout. Or the creation of a locomotion pattern that corresponds to a static body layout. The glider is, however, a dynamic body form. It can be seen as a trivial example of metamorphosis. As everybody knows, the cells in our body are regenerated in, say, every 7 years. We do not have a static set of cells at all. During puberty suddenly a bunch of cells start to undergo transitions again. With wounds we are able to regenerate tissue. Cancer might very well be in certain cases errors in the gene regulatory machinery. Aging is related to the inability to maintain this homeostatic balance with continuously changing subcomponents.

Implementation
This movie shows the result of an evolution process (which will be published in the ANTS 2010 Proceedings later this year) that creates a simplified glider. The robots are not able to dock diagonally, so a Von Neumann neighbourhood is used. The colours indicate the state of the robot module. The state is uniquely defined by a vector of all protein quantities in each module. The gene regulatory network is a matrix that takes this vector as input and produces a new protein quantity vector. When the robot is blue it wants to dock, when it is red it wants to disconnect, when it is purple it wants both. As soon as the robot modules are connected an additional mechanism comes into play. The proteins generated by both gene regulatory networks are now able to flow into the other module. The new state of a modules does not only depend on its previous state (the protein quantity vector) of itself, but also the one of its neighbour. This allows the module to "change mind" as it gets connected to another module, and request a disconnect again.

The simulation does abstract from the process of finding a robot module and docking to it. This has been shown previously in the sensor fusion movies. A combination is needed to completely implement the metamorphosis process on the real robots.

You might think you know programming languages, from VHDL to Scheme to Java, however most of the times, knowledge of the language itself is just the beginning. This week I spent three days creating a subsumption architecture using the Boost Graph Library. The latter is part of the Boost libraries, that are such an entire source of additional knowledge on top of ordinary C++ know-how.

Over time several robot architectures have been implemented. I will leave out very interesting ones (see also the internship description and the Replicator deliverables, if you are interested in those). A comparison between three architectures is given by Georgas and Taylor. They compare the subsumption architecture with the three-layer 3L approach and the reactive-concentric architecture in An Architectural Style Perspective on Dynamic Robot Architectures. Most conspicuous in this article is by the way the ease with which layers are accepted as the way to organize a robot brain. It is without doubt that the brain is built up in a modular fashion. However, how this modularity is actually materialized needs to be handled very carefully.

Notwithstanding those concerns, Brooks' subsumption architecture is the prime example of a robot architecture. The movie at the top is an appetizer of Brooks' film "Rodney's Robot Revolution" in which he wants to create a robot physically playing the board game Go. But for now we will only focus on the subsumption architecture itself. This is in incredibly simple structure. Namely of tasks or controllers, in a layered structure. Each controller might give commands. For example there is a collision avoidance controller reading infrared sensors and sending commands to the wheels to avoid collisions. However, in certain circumstances, for example when a robot needs to dock to another robot, this controller needs to be overruled. In a subsumption architecture the output of the collision avoidance controller is subsumed by the output of the docking controller. In this way an entire hierarchy of controllers can be built.

The Boost Graph Library contains a lot of predefined classes. Because of the use of generics the vertex and edge entities (or descriptors) can be easily replaced by custom made versions. This was not needed for the purpose of presenting a subsumption hierarchy by a graph though. At our SVN server you can see (check also this corresponding test unit) how this becomes incredibly easy. For example, output to GraphViz in the form of a .dot file (a kind of XML for graphs, although there are more XML-like versions) is just one line of code! Like always, feel free to use the code, it is open-source.