inFuse

h1. Software deployment

This pages presents the requirements of the set of tools that helps to easily configure, launch and run the robots on-board softwares.

h2. General requirements

* The tools must be very easy to use, maintain and update

* The tools must allow to specify and configure the softwares that will be run

* In a second step, the tools will endow means to supervise the execution of scenarios

h2. General principles

The following principles take very much after the "dala scripts" (see the git repo: git+ssh://softs.laas.fr/git/robots/dala-scripts.git , some file names of this suite are referred to hereafter. There is an important difference still, the notion of "scenario").

1. A shell script: (see shell-script/start.sh)

* sets a series of environment variables required to launch the softwares (in particular, a LOGDIR)

* Interprets the "main configuration file" that specifies which softwares must be launched (a software can be a ROS node, a Genom3 module, some utilities -- e.g. display server, redirection of the GPS correction data to the proper device, ... what else ?)

* Properly launches each software -- and warn the user in case launch failed

* Redirects standard and error outputs of each software into dedicated files in LOGDIR

A companion shell-scripts terminates "in a clean manner" all the launched softwares

2. A python interpreter is launched, loading:

* For each launched module/node, a .py file that contains:

** A function that loads the set of parameters associated to the software (mainly initialisation parameters, but also functioning mode, ...). These parameters are defined in a module/node configuration file

** A series of "generic" functions: init/start, run, log, stop-log (some doing nothing if they are not implemented in the software)

The python interpreter must know which softwares have been launched, that is, which scenario is the current one -- it could hence be run with the scenario name as a a parameter.

A question: how does the python interpreter inherits some environment variables that have been set by the shell script ? (by launching the interpreter at the end of the script ?)

h2. Some details 

* It would be nice to execute the launch shell script with the main configuration file as an argument (so that one can manage a series of configuration files). Or rather, with the name of the scenario 

* The user edits the configuration files, not the shell or python scripts. The latter are in a git repo, as well as some  exemple configuration files

* The individual configuration files are named with the same name than the main configuration file. Or rather, saved in a directory with the scenario name that contains all the configuration files

* To enable replay, also to "document" the data, the scenario files could be copied in the LOGDIR