Evolution Automator

EvolutionAutomator is a side-project that was created to facilitate launching complex and/or large numbers of experiments. It allows the user to create a single configuration file that runs several runs of one or more different experiments. Another interesting feature is that it performs a post-evaluation of the best controllers from each evolutionary run over a large number of samples, allowing you to determine which run has the best performance after the end of the evolutionary process.

Below is a general overview of the Automator's configuration file structure:

%runs:5
%maxevolutions:1

//shared configuration

%variable_name{
	
}

#experiment1{
	%variable_name
	//specific configuration
}

#experiment2{
	%variable_name
	//specific configuration
}

#experiment3{
	//specific configuration
}

In the above example, we can see several elements. The first two lines indicate the following:

• run - how many evolutionary runs will be executed for each experiment
• maxevolutions - how many evolutionary runs will be executed in parallel

The space between the first two lines and the first experiment should be filled with configuration arguments that are common between the different experiments.

Starting with a percentage sign (%) are variables. These variables can store any set of arguments, and can be used to easily share specific arguments in a sub-set of the experiments. For instance, if only 2 of the experiments use a specific evaluation function, we could put it inside a variable and then inside of these 2 experiments. Even if the variable is declared in the shared part of the configuration file, it is not used in that shared part. It will only be added inside the experiment-specific sections.

Starting with a cardinal sign (#) and the name of the experiment, we see experiment-specific sections. In these sections, particular arguments can be added or overwritten from the shared section.

An important aspect is that, in order for an experiment to be evolved, population argument set needs to be declared inside the experiment-specific section. It is not enough for the population argument set to be present in the shared configuration section.

Below we can find an example of a functioning Automator configuration file. Note the use of the variable for the --population argument set for both experiments, and the overriding of the numberofrobots argument in the second experiment:

%runs:10
%maxevolutions:5

--robots
 	classname=DifferentialDriveRobot,
	sensors=(
		PreyCarriedSensor_1=(
			classname=PreyCarriedSensor,
			id=1
		),
		SimpleNestSensor_2=(
			classname=SimpleNestSensor,
			range=2,
			numbersensors=4,
			id=2
		),
		SimplePreySensor_3=(
			classname=PreySensor,
			numbersensors=4,
			id=3
		)
	),
	actuators=(
		TwoWheelActuator_1=(
			classname=TwoWheelActuator,
			id=1
		),
		PreyPickerActuator_2=(
			classname=PreyPickerActuator,
			id=2
		)
	)

--controllers
 	classname=NeuralNetworkController,
	network=(
		classname=CTRNNMultilayer
	)

--executor classname=ParallelTaskExecutor
--evolution classname=GenerationalEvolution
--evaluation classname=ForagingEvaluationFunction
--environment classname=RoundForageEnvironment, steps=1000

%pop {
	--population classname=MuLambdaPopulation
}

#forage{
	%pop
	--postevaluation samples=100
}

#forage_5robots{
	%pop
	--robots +numberofrobots=5
	--postevaluation samples=100
}

Running a complex experiment on Conillon

The advantage of using EvolutionAutomator and Conillon is that we can leave experiments running for long periods of time without having to manage the start of new experiments or running post-evaluations manually. In order to do this, it is necessary to:

• Generate a runnable jar of the EvolutionAutomator project. Make sure that the project includes all the necessary projects (JBotSim, JBotEvolver, and any other you use)
• Copy the jar and the configuration file to computer that can access Conillon
• Change the executor argument set to use ConillonTaskExecutor (--executor classname=ConillonTaskExecutor)
• SSH to the computer where the experiments will run and launch a screen
• Launch the jar with the name of the configuration file as an argument (java -jar FILE.jar CONFIG.conf)
• Detach from the screen and wait for the results (CTRL A + D)