Skip to content

tutorials vrx_docker_mwes

Jessica edited this page Sep 10, 2023 · 9 revisions

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 [email protected]/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
Clone this wiki locally