This package contains some stochastic local search algorithms for AutoMoDe.
"localsearch.py" file contains the current algorithm. The "utilities.py" file in the same directory just contains a number of functions that don't really fit into the localsearch.py file.
The "controller" referenced in the localsearch.py file is an instance of the (abstract) class AutoMoDeControllerABC defined in "automode.controller.AutoMoDeControllerABC.py". More correctly it is either an instance of AutoMoDe-FSM or AutoMoDe-BT that both implement the abstract base class AutoMoDeControllerABC. These two classes describe the control software for the robot (either as FSM or BT).
Both classes make use of the modules (behaviors and conditions) defined in "automode.modules.chocolate.py" (here again I have abstract base classes (in "modulesABC.py") in case we are going to extend the set of modules to another version of AutoMoDe). These classes are representations of the data (type and parameters) of the modules of AutoMoDe.
The general idea of the whole setup is as follows. The python program (the local search) creates a representation for a controller. It has no knowledge about the meaning/implementation of the individual modules and is working "blindly" on the design of the control software ("Blindly" in the sense that the local search has no insight in the workings of the modules, the mission or anything else. That is to say that we can simply import a different python file with modules or set a different mission and the local search will behave the same). However the local search needs some information on how good or bad a piece of control software is. For the evaluation it passes the control software (or again a representation thereof) to our implementation of AutoMoDe and AutoMoDe returns a single value (the performance measure/objective function). According to a number of these values, the local search decides to keep or discard the current solution.
We are always talking about AutoMoDe as if it is a single program, but it's not. AutoMoDe is our implementation of the modules and it uses the argos3 simulator to test the performance.
ArGoS3-beta48 is the version of the robot simulator that we use. The ARGoS3-epuck v48 is a plugin for argos that implements the epuck robot that we are using for our experiments. Together these two programs form our simulating environment that we use to perform our simulations. The focus of them is to provide us with the performace quickly but accurately (that is as close to reality as we can get).
The repositories of AutoMoDe-FSM and AutoMoDe-BT contain the modules and the control architecture for AutoMoDe. They make use of the epuck-DAO (an abstraction layer that gives us limited but focussed access to the sensors and actuators of the epuck) and the loopfunctions (implementations that set up and control the missions; think of what you would have to do in a real experiment: setting up the robots, counting the final score, ...). Together these implementations form what we usually refer to as AutoMoDe (and it is in fact missing the automatic design ;-) ).
When you call the AutoMoDe executable you usually have to supply three arguments: seed, mission and controller. The seed is simply the seed for the RNG and if it is kept the same (together with the other arguments) then the result is the same as well. The mission (or scenario) is a XML file (with either .xml or .argos ending) that describes the layout for the arena, the number, type and controller of robots and the loopfunction that performs (supervises) the experiment. There are a number of additional information included in the scenarios/missions but I would say it's only technical (think of it as everything you would want to know if I tell you to test my controller on the real robots).
The controller finally is a special string that is translated from AutoMoDe into an actual instance of control software that can run either in simulation or reality. This string is usually generated by hand (for testing), F-Race (Vanilla) or I-Race (Chocolate and Maple). We are now trying to generate this string with the local search.
Once AutoMoDe has all of these arguments, it starts argos3 with the setup described in the mission file and all robots get the controller. Argos3 then runs the simulation and the loop function (from the mission file) prints the final score. This final score is then read by whatever optimization implementation is used.
As a short description for the important directories of my python program:
-
automode: Descriptions of control architecture and modules; translates FSM and BT from a form that the local search understands into one that AutoMoDe understands
-
config: contains configuration files for the localsearch (I'm refactoring the flow of information here)
-
execution: takes care of calling AutoMoDe and getting the results back; should technically also work in parallel on the cluster (reducing the waiting time) but is not for various reasons at the moment (also subject to refactoring and alternative implementations at the moment)
-
localsearch: contains implementations of local search algorithms (at the moment only one, but will contain more in the future)
The important top-level implementations (also are refactored heavily at the moment, so the total composition will change) are:
-
main.py: Starts the local search
-
evaluate_controller.py: If you have a controller from an alternative source (manual design, I-Race) or just want to retest a controller generated by the local search you can use this file. It is probably broken at the moment.
-
localsearch_setup.py: Was supposed to be used as a setup for both main.py and evaluate_controller.py. I will drop this file in my refactoring and include a more powerful configuration.py file.
-
submit_localsearch.py: Was supposed to replace the localsearch_*.sh, automode_localsearch,sh and submit_localsearch.sh files. I never finished this file and it will be replaced in my current refactoring process.
-
localsearch_*.sh, automode_localsearch,sh and submit_localsearch.sh: Scripts that I used to submit my jobs on the cluster. Not necessary for local testing
The local search can be configured using JSON files.
When calling automode_localsearch.py with the "run" subcommand, an experiment file is expected. This experiment file should contain all necessary configuration that will be made available through the settings.py file. The configuration data should be structured as named dictionaries and each dictionary dict will be available as settings.dict
When calling automode_localsearch.py with either the local or submit the syntax is supposed to be a little bit different. The main experiment file (supplied by -e) needs to contain a number of dictionaries describing the experiments. For each experiment, the key to this dictionary will be used as the job_name. The values of the experiment need to contain at least entry: configuration with the path to the config file. This config file will be loaded (including all of it's include_files). If all the experiments use the same config file, it can also be set at the top-level.