To avoid environment-specific problems, the environment is run in a Docker container. The development workflow with Docker basically consists of the following steps:
- Build image containing all dependencies that change very rarely by executing
build-image.sh - Run a container of the image (this projects code is mounted as a volume) by executing
run-container - Attach to the container shell by executing
exec-container-shell.sh - Execute
./launch.shwithin the launched shell, which builds the project and starts the simulation
Everything that doesn't need to be redone (or is only changed very rarely) when modifying this projects behavior, should be built into the image. This includes the fetching of dependencies and an initial build to cache the built dependencies and be able to build faster when using the image later.
You can execute this shell script to build the image. In the script a Dockerfile is used to build an image called arena.
To launch the environment, run a container of the created image by executing this shell script.
In this script, a container of the previously built image is created through a docker-compose file. Also, in this file the X11 server is mapped to the outside to show the GUIs of the windows opening in the container on the host system.
For development we recommend to do remote development inside the container with VS Code. This allows to view the filesystem as well. To allow development with Python, the pip packages flake8 and autopep8 are already installed in the Dockerfile.
First, you need to install the Remote Development extension pack.
Next, build and run the image as described in the steps above.
Last, execute the action Remote-Containers: Attach to Running Container... in the command palette (Ctrl+Shift+P) and select the container name (default: ans-env).
Alternatively, you can start a bash shell inside the container by executing the exec-container-shell.sh shell script.
When you have a shell inside the container, you can launch the simulation with the launch.sh script, which is mounted in the users home directory inside the container. This script rebuilds the project (catkin_make), sources the ROS setup scripts and launches the simulation (roslaunch).
The output for each training run including the model parameters are saved in the logs directory defined through the ROS parameter log_container_path of the training_coordinator node. You have to configure the number of runs that you want to keep the logs for by specifying the ROS parameter number_logs_to_keep.
Also, you need to specify the ROS parameters checkpoint_frequency_in_steps to define how often the current model parameters should be saved in the checkpoint directory inside the log directory of the current run. This is useful, if the training fails, because you don't have to start training from scratch, but can continue from the last checkpoint.
If you want to keep specific parameters permanently, copy them to a different directory than the logs directory, so they don't get cleaned up.