tutorials vrx_docker_mwes - osrf/vrx GitHub Wiki
The vrx-docker
repository contains scripts and Docker images needed to run the VRX competition.
- These include
Dockerfile
s 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 aDockerfile
for the VRX 2022 competition that builds a workspace from source code on the host. -
vrx_2023_simple
: An exampleDockerfile
for VRX 2023, using ROS 2 and Gazebo Garden.
-
- More details about all three images are documented in the vrx-docker repository, here.
In this tutorial we use the Dockerfile
provided for the vrx_2023_simple
as a starting point for developing a competitor image.
- 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>
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.
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
:By default this will create a local directory namedgit clone [email protected]/myteam/myrepo.git
myrepo
. - Use a text editor to modify the
COPY
command in the following line from the providedDockerfile
so it copies the repo you cloned from the host file system to the desired path in the image. For example:COPY my_source /vrx_ws/src/vrx
COPY myrepo /vrx_ws/src/myrepo
- Now use the same
docker build
command to build the image with your source code.
- 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 theDockerfile
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.
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 |
---|