Container images

EROBS provides four container recipes. Choose one based on whether you need the robot stack, a Bluesky client, or EPICS integration.

Image inventory

Recipe	Purpose	Source input	Automation
`docker/jazzy/Dockerfile`	Main Jazzy robot-stack image with ROS, motion and camera dependencies	Clones EROBS `jazzy_dev`, then imports external repositories	Manual workflow selection `erobs-jazzy` or `all`
`docker/bsui/Dockerfile`	Full Bluesky/ROS reference environment	Clones `jazzy_dev` and builds a selected workspace	Manual selection `beambot_bsui`; local helper
`docker/bsui-minimal/Dockerfile`	Smaller client source set: interfaces, wrappers and CMS data	Copies those directories from the local build context	Local helper only
`docker/epics/Dockerfile`	Jazzy/EPICS branch-specific environment	Clones EROBS `epics_bridge`	Manual selection `jazzy_epics`

“Minimal” describes the selected EROBS source set. The minimal recipe starts from osrf/ros:jazzy-desktop-full; it is not a ROS-core-only image.

The Jazzy recipe contains the main robot stack. Check the deployed image revision and camera SDK compatibility before using it.

A local build does not necessarily build local code

The main Jazzy recipe clones from GitHub inside the image. Changing a local Python file and rebuilding that recipe does not automatically include the change. Its CACHEBUST argument forces the clone step to be reconsidered; it does not pin the cloned branch to a commit.

For example, this is a local image build command, not a publish command:

docker build -f docker/jazzy/Dockerfile -t erobs-jazzy:local .

Before treating the result as a reproducible deployment, record the image digest, Dockerfile revision, cloned EROBS commit and imported repository commits. A workflow tag containing the checkout SHA alone is insufficient: the recipe can clone a different branch revision during the build.

The main image skips selected packages, including the local OnRobot packages and ZED-related builds. Check the recipe’s package selection when adding a device.

Current recipe mismatches

The minimal recipe’s COPY inputs conflict with the root .dockerignore:

The recipe copies src/beambot_interfaces, src/bluesky_ros and src/cms.
.dockerignore excludes everything except the Docker directory, including those inputs.

Correct that recipe/context combination before using it. Docker cannot copy files excluded from the build context.

The Jazzy and EPICS recipes contain commented VNC copy/startup lines, and VNC packages have been removed from their package lists. docker/jazzy/start-vnc.sh remains in the repository, but the current recipes do not start VNC.

Older container examples pass use_fake_hardware to the main beambot launch. The launch declares use_mock_hardware. A mock deployment also needs an explicit beamline configuration and decisions about vision and pipettor servers; use setup and the launch reference.

Publishing and client networking

.github/workflows/docker-publish.yml is manually triggered and pushes image tags to GHCR. Its all option intentionally builds only the Jazzy image. The reference Bluesky and EPICS images need explicit selections; the minimal image is not a workflow option.

docker/img_build.sh also pushes the Bluesky images after building and tagging them. Use docker build for a local-only build.

ROS clients and the robot container need compatible discovery/domain settings and reachable ROS transport. The recipes include site-specific Fast DDS discovery settings. Existing host-network/IPC examples are deployment choices for that environment, not a universal requirement that every container must share the host PID namespace. Start from the selected ROS networking configuration and verify discovery before sending any goal. The images do not set ROS_SUPER_CLIENT, so ros2 topic list or ros2 node list inside a container can show only part of the graph; export ROS_SUPER_CLIENT=TRUE in the shell you use for introspection, and check that the discovery-server hostnames resolve.