... Replicator
YARP 
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!
Robotics development is, in some ways, like natural evolution. Consider robot software. Every piece of software has its niche: the environmental conditions within which it can be used. Within this niche it will grow and change and perhaps expand to nearby niches. Some niches are large (standard PCs), some are medium-sized (for example robots like Khepera [21], Pioneer [18] and AIBO [23] to mention a few), and some are tiny (a newly developed humanoid). Software evolves quickly as new technologies get proposed and hardware changes; if trapped in too narrow a niche it tends to become obsolete and die, together with the efforts of the developers who have contributed to it. Robot hardware is subject in turn to the changes in the commercial and industrial environment. In academia, software and hardware designed for robotic projects are prone to obsolescence, because although graduate students may be talented developers they are rarely experienced and disciplined system engineers. Also, usually the development of a robotic platform is not the main goal of the people who are working on it but simply a means to an end.
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 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!
Gene Regulatory Network for a Glider consisting out of 2 Modules
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.
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.
Boosting
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.
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.
Internships
One internship is about artificial intelligence: cognitive robotics. Cognitive modeling using global workspace theory. A competing sets of modules that fight for a place on stage. The description of this internship can be found in the PDF file
Internship - A Theater in the Mind of a Robot Organism. The second internship is about artificial life: metamorphosis in robotics. Robot snakes changing in robot spiders and the other way around. The description of this internship can be found in the PDF file
Internship - Robot Metamorphosis (gene regulatory networks to implement metamorphosis). Both internships are on a masters level (nothing more, nothing less).This is of course self-advertisement, but our company is really a challenging place for internees, there is a lot of state-of-the-art research going on. We are a small company, 25 people, but because our products are commercialized within daughter companies, it is really possible to do pure research in our mother company. We have had several internees and PhDs before. From the University Utrecht, Hogeschool Rotterdam, Rijksuniversiteit Groningen, TU Eindhoven, TU Delft and the VU. In case you wonder - as almost always at Almende - all the code that you develop will be open-source. Feel free to contact me for any type of additional information. See my email address or telephone number at http://replicator.almende.com/contact.php
Some related information can be found in the very extensive Replicator Deliverable 3.3 in the Download section (you need to become a member of this blog for that).
To be selected for this internship, personal interest in the topic is considered most important. Don't be set back by the amount of prerequisite knowledge that seems to be expected of you. The final internship description will be written together with you and the supervisor at your university. It is definitely meant to fit an internship/thesis on a masters level (nothing more, nothing less).
See also http://sense.almende.com for an internship regarding pattern recognition in wireless sensor networks.
OpenAL for Simulations
The big problem is that OpenAL does not allow for multiple listeners. You will find many people asking for this functionality. First of all, it is necessary if the game actors that are not players need to hear something. If you are playing a game with intelligent computer-driven opponents, they might hear you coming closer! This is implemented in no game that I know off. It is quite complicated to implement artificial intelligence for such game actors, and probably game developers yet do not feel ready for it. Secondly, and most important in the Replicator project, it is important to have multiple listeners in a simulator with multiple robots. To have only one listener in the environment, means that you can only emulate one microphone. With a robot swarm or a robot organism this is of course not enough. There is no open-source software available that implements that however! Also Player/Stage/Gazebo or Webots do not implement sound for multiple robots. This is because all that robot simulation software is built on top of OpenAL which does not support it.
So, what to do? First I emailed Chris Robinson who created the openal-soft implementation. In the meanwhile I started to implemented openal-sim. First of all I played around with OpenAL in combination with PulseAudio. It is possible to have multiple listeners showing up in the PulseAudio console "pavucontrol". However, it is not possible to redirect individual capture streams to recording streams. So, what that means is that I can only mix together what multiple listeners hear in one big mix. But help is near! In the OpenAL implementation there is a so-called "Wave File Writer" device. This allows for writing to a file on the disk. Rewriting the openal-soft implementation so that multiple wave files can be written in parallel and we are halfway! Then it is only necessary to read the data back. For that I choose to use the already existing RingBuffers. This is a well-known programming solution that stores data in a circular construction in which when the user comes to the end of the RingBuffer the write pointer is automatically set to the beginning again. This all nicely encapsulated with proper mutexes, so that it is impossible to read when someone is just writing. Anyway, this also allows for retrieving the sound mix concocted by OpenAL with attenuation, Doppler and eventual other effects to be retrieved again by microphones in the simulator! Then Chris emails back that it is a nice problem and perhaps something he might implement in the future. Not needed anymore!
The result can be checked out from the Almende SVN Server. And a file to test it at dtJack. This is not the end of the story, the Delta3D simulator also needs to be adapted to use openal-sim. You will find this at dtAudio. All this is implemented within a week, so don't expect maturity!
With this software set up it is finally possible to have multiple robots in a simulator each hearing each other. Something never shown before! Now it becomes possible that robots are gonna behave like a bunch of birds, tjilping/twittering different tunes! Each of them attracted by sounds in its own way!
Go to page >>
Software
Goal Replicator/Symbrion
Slideshow
News for 2010
RSS Feeds
Our news can be syndicated by using these rss feeds.
