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.

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

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 ?)

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