RoboGen Software Suite
The Robogen software is designed to perform artificial evolution for the Robogen project. The evolution engine is responsible for the most of the conceptual part of the evolution process (e.g. population generation, selection, mutation, and reproduction), while the simulator is only there to do the fitness evaluation. The two components work together to perform the artificial evolution of Robogen robots. They are executed as two independent processes that communicate over the network.
More detailed information with regards to the implementation of RoboGen is available in this presentation.
Evolution Engine
The evolution engine takes care of population generation, selection, mutation, and reproduction.
The engine comes in two flavors: Body and brain co-evolution, and evolution of the brain only. The brain evolution mutates weights and biases of a given robot’s neural network, while the body and brain co-evolution mutate both the morphology tree and the associated neural network.
At the evaluation step, the robot description of each individual is sent to the simulator in Google Protocol Buffer format in order to obtain their fitness.
Body composition and encoding
RoboGen robots are composed of predefined and parameterized components, which are assembled together via slots and plates. Within the evolution engine, these robots are each represented by a tree structure, where each node represents a body part and each link represents a connection between body parts.
Since each RoboGen robot requires one CoreComponent, a node representing this body part always forms the root node of the body tree. The CoreComponent has four possible connection points, and so it can have up to four possible child nodes (arity=4). In practice this means the representation of the CoreComponent has four pointers, which are each either NULL, meaning it has no child at the corresponding slot, or point to a child node, which represents another body part. In addition to child-node pointers, each node maintains the type of body part that it represents, an orientation relative to its parent (given by an integer value representing increments of 90°), and evolvable parameters (if applicable).
 |
 |
| An example of robot’s body tree representation (left) and its physical simulated model (right) | |
Brain composition (NN) and encoding
In RoboGen, the brains of robots are Artificial Neural Networks (ANNs). The body of a robot, whether being evolved or fixed, implicitly defines the inputs and outputs of its ANN controller. Specifically, each sensor on the robot serves as an input to the ANN and each motor requires an output neuron. Additionally, a robot’s brain may possess a number of internal or hidden units not directly connected to any inputs or outputs. Hidden units may be manually defined by the user or may be added by mutations. By default, every hidden and output neuron computes a sigmoid activation function and connects to every hidden and output neuron (including itself). Moreover, every hidden and output neuron receives input from every input neuron. Each of these connections has an evolvable weight, and every sigmoid hidden and output neuron has an evolvable bias included in the genome representation
 |
| An example of an Artificial Neural Network with three sensors (input neurons), one hidden neuron and two motors (output neuron) |
One notable difference between the ANNs in RoboGen and “classical” recurrent ANNs is the possibility of oscillator neurons, as these have been shown to drastically speed up the evolution of effective controllers for certain tasks. Specifically, these oscillator neurons do not receive any input, but rather output a sinusoid oscillation as a function of time. Oscillator neurons may be pre-specified when starting an evolution, but also any new hidden or output neuron may be chosen to be an oscillator neuron with a user-specified probability. While a sigmoid neuron has a single evolvable parameter: its bias, an oscillator neuron has three: its period, phase-offset from a central clock, and its amplitude.
Evolutionary algorithm
The evolution algorithm is capable of operating in two modes: brain only, which only evolves the controller or ‘brain’ of an existing robot morphology (see below), and full, which evolves both the brain and ‘body’ (morphology) of robots. In brain only mode the body tree must be manually defined (or previously evolved). When using full evolution, it is possible to either begin from an existing morphology or generate body trees at random. In the latter case, random robots will be “grown” starting with a CoreComponent root node, and randomly attaching additional nodes so that ultimately it has a number of components within a user-specified range. Whenever full evolution mode is used, it is also possible to configure which body part types are allowed. When using full evolution, new body trees are created by mutating clones of well-performing robots. Specifically, one or more of the mutation operators specified in Table I are applied based on user-configurable probabilities.
| Mutation Operator | Description |
| NodeInsert |
Insert a random node at a random location in the body representation tree.
|
| NodeRemove |
Remove a random node from the body tree representation.
|
| SubtreeDuplicate |
Duplicate a randomly chosen subtree and insert it at a random location the body tree.
|
| SubtreeSwap |
Swap two randomly chosen subtrees of the body tree representation.
|
| SubtreeRemove |
Remove a randomly chosen subtree from the body tree representation. Unlike NodeRemove which attempts to remove a node and propagate its children upwards, SubtreeRemove removes a node and all of its descendants.
|
| MutateParam |
Mutate a randomly chosen parameter of a randomly chosen node. For the purpose of this operator, a node’s orientation relative to its parent is also considered to be a parameter.
|
|
Body tree mutation operators
|
|
Regardless of whether full evolution or brain only evolution is being run, it is [also] necessary to represent and apply variations to the brains of robots. To do this, all of the parameters (weights, biases, and oscillator params) of each brain are considered to be a string of real valued numbers.
Crossover is possible when evolving ANNs with a fixed topology (e.g. doing brain only evolution with 0 probability of adding additional hidden neurons), but otherwise is disabled for simplicity. When two brains are crossed over, a single point crossover is applied to the string of the parameters with a configurable probability. Whether crossover is enabled or not, all of the parameters of a robot’s brain may be mutated with Gaussian mutations (based on configurable probabilities and magnitudes).
Finally, while the representation and variation mechanisms have been explained, it is also important to understand how robots are selected for reproduction. When evolving brains with HyperNEAT, this is handled internally using NEAT’s speciation mechanism, but otherwise survivor selection (based on the μ +/, λ formalism of Evolution Strategies) is first performed (with all parameters configurable), and then tournament selection across the whole parent population is used, where the tournament size is configurable. In all cases, the survival and reproduction chances of each individual are informed by its fitness value, which is computed by the simulation engine, as will be explained next.
Simulator
The simulator receives the robot body and brain description from the evolution engine and evaluates its fitness depending on the chosen scenario. For the physical simulation of the robot, the Open Dynamics Engine is used with simplified robot parts (boxes and cylinders instead of complex geometries). The robot simulation is computationally the most expensive part of the evolution, and it is thus best to make it as simple as possible.
In other terms, the simulator translates the abstract representation of a robot into a physical model along with code for operating its brain. The simulator places this robot inside of a user-defined, simulated environment and evaluates it in a scenario that is either built-in to RoboGen or is written custom by a user using a small amount of ECMAScript/JavaScript. See Obstacle Configuration to build an environment.
There are many properties of the simulation that are configurable such as the time step used for advancing the simulation (more complex robots/environments require a smaller time step), the length of the simulation, the actuation frequency of the robot’s brain, the gravity, and the friction coefficient used for contacts with obstacles and the ground. It is also possible to configure the simulator to inject noise into the simulation in order to evolve robots more likely to exhibit robust behaviors, and there are a number of options related to penalizing robots with behaviors that are unlikely to work well in reality. Finally, when using noise and/or when attempting to evolve behaviors for a task that requires responding to sensory stimuli, it is possible for each robot to be evaluated multiple times, possibly starting in different locations or orientations, which filters out robots with brittle solutions that “overfit” a given environment. A complete list of customizable parameters of the simulation is available in Simulation Settings.
Target scenario
Once an environment and the simulator settings have been defined, it is necessary to specify the fitness function or scenario being used to evaluate the robots. RoboGen offers two built-in scenarios: racing and chasing.
- Racing: The racing scenario rewards robots for moving as far as possible in the allotted time
- Chasing: The chasing scenario rewards robots for being as close as possible to a light source for the duration of a simulation.
- Customized: While the racing and chasing scenarios combined with the ability to customize the environment already offer quite a bit of flexibility in the evaluations, many interesting tasks require the user to define their own scenario. This is done by writing a small amount of JavaScript, which interacts with the provided API. With these scripts, users may programmatically alter the simulation and are free to compute fitnesses any way that they see fit. To define a scenario, complete details are given in custom scenario section.
Robot viewer
The robogen-file-viewer program allows the user to replay visually what happens with a robot design in the Robogen simulator. OpenSceneGraph is used along with CAD models of the robot parts.