SIERRA Design Philosophy

This document outlines the main philosophy behind SIERRA’s design, how it can be used, and so forth. It really boils down to a few core ideas.

Single Input, Multiple Output

During stage 1, SIERRA generates multiple experiments via multiple experimental run input files all from a single template input file, which must be specified on the command line. SIERRA does not follow any references/links to other XML files in this template input file, greatly simplifying the generation process and improving reproducability of experiments (i.e., less cryptic/subtle errors because of a ROS <include> which is different between the package versions installed on one system and another).

Assert Often, Fail Early

If a condition arises which SIERRA can’t easily handle, abort, either via an uncaught exception or an assert(). Don’t try to recover by throwing an exception which can be caught at a higher level, etc., just abort. This gives users confidence that if SIERRA doesn’t crash, then it is probably working properly. As a result of this, any try-catch blocks which do exist should always be in the same function; never rely on raised exceptions to be caught at higher levels.

Never Delete Things

Because SIERRA is intended for academic research, and experimental data can be hard fought, SIERRA tries to guard against accidental deletions/overwrites of said data that users actually want to keep, but forgot to change parameters to direct SIERRA to keep it. Therefore, we force the user to explicitly say that deleting/overwriting is OK when it might cause irreparable damage to experiment results (i.e., only pipeline stages 1 and 2). Overwriting is OK in later pipeline stages since those files are built from stage 1 and 2 files, and can be easily regenerated if overwritten.

Better Too Much Configuration Than Too Little

SIERRA is designed to be as modular and extensible as possible (just like ARGoS, ROS, Gazebo, etc.), so that it can be adapted for a wide variety of applications. When in doubt, SIERRA exposes relevant settings as configuration (even if the average user will never change them from their default values).

Swiss Army Pipeline

SIERRAS 5-stage Pipeline is meant to be like a Swiss army knife, in that you can run (mostly) arbitrary subsets of the 5 stages and have everything work as you would expect it to, to help with tweaking experimental design, generated graphs, etc., with minimal headaches of “Grrr I have to wait for THAT part to run again before it will get to re-run the part I just changed the configuration for”.