Running Simulations in Gazebo

If you do not need visual access to Gazebo, and instead would like to run system tests for Seawolf-8 in a headless environment, a docker container can be used. A docker container hosted here has all the necessary components to run a simulation of Seawolf-8. In order to get this container on your local system you can use the command

sudo docker pull namr2000/seawolf8-dev

A container will now exist on your system. If you would like to interact with this container in an ssh-like way you can run the command.

sudo docker run -it namr2000/seawolf8-dev

you can now run commands in the container, and explore its contents. Something important to note is that the seawolf8 software repository is not included in the container, and this is by design. You can pull in the latest version from github using the standard git pull commands. Once the software is in the container, you can run test_start.sh to run system level tests in a headless simulator. You can exit the container by typing the exit command

Important things to note

• changes made to the container while in the interactive session are NOT saved, even locally. You must use the commit commands to save any changes, but its not recommended. This can be done by finding your interactive sessions name through the command sudo docker ps, then committing changes to a running interactive session with sudo docker commit <SESSION_NAME> namr2000/seawolf8-dev
• No graphical applications can be run while in docker (currently), it has no access to X server, and if you try to launch rqt_graph or other graphical tools, they will not run.
• you can launch another terminal instance in the same docker instance with this command docker exec -it <SESSION_NAME> bash the session name can be found through sudo docker ps

Launching from a dockerfile

If you don't want to clone the repo and build it everytime you want to run some tests, its much quicker to run the container via dockerfile. The dockerfile included in the repo is setup to execute system tests on run. If you're in the same dir as the dockerfile, you can use it with these two commands

sudo docker build -t s8t .

sudo docker run s8t

s8t is just a name and you can choose whatever name you like. Something important to note is that the dockerfile uses the contents of your local Seawolf-8-Software directory in the container, not whats on github.

Also important to note is that sometimes you cannot stop the container with Control+C, so instead you must open a second terminal, and run the command sudo docker stop <SESSION_NAME>

Some details about how test_start.sh works, and other docker quirks

While trying to get github actions to behave properly, I learned there are a lot of quirks with docker, specifically when trying to run applications that generally except a live interactive user to be running them. There are two types of bash shells, login shells and non-login shells, which generally tell the terminal if .bashrc should be sourced, and other things of that nature. It is very important for .bashrc to be sourced for all of ROS to work, so you need to be sure that bash is started in login mode. In a docker file this can be achieved with this line

SHELL ["/bin/bash", "-c", "-l"]

This is not the end of the problems that come with running these programs through a docker container, gazebo for some reason demands that the terminal be a "TTY" terminal. This terminology makes little to no sense, but essentially what it is saying is that not only is it a login shell, it is a shell that readily expects input to be entered into it. Despite the fact that gzserver doesn't except any input, it requites this type of terminal, probably because of a dependency. using the -it flags with docker run will solve this issue, but if you're running from a dockerfile, this isn't an option. The workaround I found for this is to run the launch script through a program called unbuffer which is part of the expect package. if you set the entrypoint to unbuffer ./test_start.sh, the program runs with no issues.

Another dockerfile quirk you need to know if you ever write one of these files is that each command runs in a separate terminal instances from one another. Meaning sourcing or other environment changes won't affect following commands, for this reason it is helpful to make compound commands with ; or && a good example of this is this command

RUN source /opt/ros/melodic/setup.bash; catkin_make clean; rm -rf build; catkin_make

which builds a ROS project