Project

General

Profile

Actions

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)
  • A .py file that contains "meta-calls" to the modules/nodes (e.g. "init" runs the "init" requests of all the modules)

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 and questions

  • 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
  • the situation will be a bit more complex on Minnie, because the softwares are launched on 2 different CPUs (the dala-scripts allowed this, in a bit tricky manner)
  • What will be the syntax of the main and modules/nodes configuration files? (python? Any other easy syntax already understood by python?)

Updated by Simon Lacroix over 5 years ago · 5 revisions