tutorials vrx_docker_mwes

Minimal Working Examples of Competitor Images

Resources in the vrx-docker repository

The vrx-docker repository contains scripts and Docker images needed to run the VRX competition.

• These include Dockerfiles for the VRX server docker image, as well as three examples of competitor images:
  • vrx_2019_simple: A minimal competitor image used to test the VRX server in the VRX 2019 competition
  • vrx_2022_simple: A minimal competitor image used to test the VRX server in the VRX 2022 competition
  • vrx_2022_starter: A slightly more developed example of a Dockerfile for the VRX 2022 competition that builds a workspace from source code on the host.
  • vrx_2023_simple: An example Dockerfile for VRX 2023, using ROS 2 and Gazebo Garden.
• More details about all three images are documented in the vrx-docker repository, here.

The vrx_2023_simple image

In this tutorial we use the Dockerfile provided for the vrx_2023_simple as a starting point for developing a competitor image.

Download and build:

• Instructions for building this image are available in the vrx-docker repository, here.
• Note that these instructions omit the Github username and tag when building the image.
  • This is fine for local development. However, the image will need to be renamed before pushing to the Dockerhub repository.
  • You can accomplish this with the docker tag command. For example:

  docker tag <my_image> <username>/<my_image>:<tag>
  

Adapting the Dockerfile

The Dockerfile provided is organized into the sections as follows:

• setting environment variables
• setting locale information
• installing utilities
• installing ROS packages
• installing optional development tools
• importing and build a workspace from source
• adding startup scripts
• adding additional customizations
• setting the entrypoint Most of these sections are self-explanatory and can be easily modified to set variables, or add or remove packages. The example below walks through how to substitute and develop with a different source code repository.

Building your own repository

In this example we assume that, instead of the vrx repository, a team would like to build a different source repository. This can be accomplished as follows:

• Clone your repository into the same directory as your Dockerfile:

  git clone git@github.com/myteam/myrepo.git
  

  By default this will create a local directory named myrepo.
• Use a text editor to modify the COPY command in the following line from the provided Dockerfile

  COPY my_source /vrx_ws/src/vrx
  

  so it copies the repo you cloned from the host file system to the desired path in the image. For example:

  COPY myrepo /vrx_ws/src/myrepo
  

• Now use the same docker build command to build the image with your source code.

Development workflow

• Once you have set up the image to build your code, you can work in your repository locally.
• Whenever you rebuild, the COPY command will detect any changes to your source code and rebuild the image as necessary.
• This feature of the COPY command makes it particularly well-suited for a development workflow.
• In contrast, if you were to clone a source repository directly into the image using the a RUN command, Docker would have no way to detect a change in the remote repository, and would always use a locally cached version unless you were to modify the Dockerfile itself or force a full rebuild with the -no-cache option. Consequently, this approach can cause your image to go out of sync with your latest changes and is usually not recommended.

Bridging ROS1 <-> ROS2

While the VRX 2023 competition uses a ROS2 API for communication, it is possible to run ROS1 nodes within the competitor docker container via the use of a bridge. This is not officially supported but is permitted. For a minimal working example of a ROS1-ROS2 container that bridges the VRX task message, see this repository.

Back: Option 2: Scripted	Up: VRX Docker Image Overview	Next: Troubleshooting Trial Runs