Glossary

Fictionlab > Glossary > Docker container

Docker container

Docker container – definition

A Docker container is an isolated runtime environment created from a container image and executed by a container runtime. In mobile robotics, it packages an application together with its declared user-space dependencies, configuration files, and runtime entry point. The container shares the host operating system kernel but has isolated processes, filesystem mounts, network settings, and can have resource limits.

On Linux, Docker implements containers using operating-system mechanisms such as Linux namespaces and control groups (cgroups). The image format and runtime behaviour are standardised by the Open Container Initiative (OCI). An OCI image contains ordered filesystem layers and metadata. A container is a runtime instance of that image.

For a UGV, a Docker container can isolate a ROS 2 node, perception pipeline, simulation environment, map server, or data-recording service. It does not virtualise the robot hardware. Access to cameras, LiDARs, serial ports, CAN interfaces, GPIO, and GPU devices must be explicitly granted to the container.

Docker containers in ROS 2 systems

ROS 2 applications are commonly distributed as source workspaces, Debian packages, or container images. A container image can include a specific ROS 2 distribution, such as ROS 2 Humble Hawksbill, a colcon workspace, package dependencies resolved through rosdep, and an application launch command.

ROS 2 communication uses DDS middleware. Nodes in separate containers can communicate if their DDS discovery traffic and transport configuration are compatible. On a single robot, host networking is often used because multicast-based discovery may otherwise be limited by Docker bridge networking or firewall rules.

  • Image: package definition, for example ros:humble-ros-base plus a compiled ROS 2 workspace. Image content is immutable, although tags can be reassigned.
  • Container: a runtime instance created from an image, which can run one or more processes.
  • Volume or bind mount: persistent or host-provided storage, used for maps, rosbag recordings, calibration files, and logs.
  • Device mapping: controlled exposure of hardware, for example /dev/ttyUSB0 for a serial LiDAR or /dev/video0 for a V4L2 camera.
  • Network mode: configuration affecting ROS 2 DDS discovery and data transport.

ROS 2 does not require Docker. It can run directly on Ubuntu or another supported operating system. Containers are an engineering choice that improves repeatability when the same software must run on a development workstation, a CI runner, and an onboard computer.

Container architecture for mobile robots

A practical UGV deployment separates hardware-dependent functions from higher-level applications where possible. A sensor driver may run in one container, while navigation, visual perception, and telemetry run in other containers. This separation makes software updates and fault diagnosis more controlled, but it also introduces network and configuration dependencies.

Component Typical ROS 2 interface Container consideration
2D LiDAR driver sensor_msgs/msg/LaserScan Requires serial or USB device access and stable device naming.
Depth camera driver sensor_msgs/msg/Image, sensor_msgs/msg/PointCloud2 Requires USB access; GPU acceleration may require NVIDIA Container Toolkit.
Odometry interface nav_msgs/msg/Odometry Requires access to the rover controller interface and consistent frame IDs.
Nav2 stack geometry_msgs/msg/Twist, nav_msgs/msg/Path Must use the same ROS domain, TF tree, and map storage as the rest of the system.

The standard ROS coordinate-frame convention is defined by REP 105. A containerised navigation stack must receive a valid transform chain, typically from map to odom and from odom to base_link. Container boundaries do not change TF2 requirements.

Example ROS 2 Docker configuration

The following example starts a ROS 2 Humble image with host networking, a mounted workspace, and access to a serial sensor. The command is appropriate only when the host operating system, ROS middleware configuration, and connected device are verified.

docker run --rm -it \
  --network host \
  --device=/dev/ttyUSB0:/dev/ttyUSB0 \
  -v ~/robot_ws:/workspaces/robot_ws \
  -e ROS_DOMAIN_ID=20 \
  ros:humble-ros-base \
  bash

A Compose file can declare repeatable services for development or deployment. The example mounts persistent map data and starts a ROS 2 launch file.

services:
  navigation:
    image: registry.example.org/ugv-nav:humble
    network_mode: host
    environment:
      ROS_DOMAIN_ID: "20"
    volumes:
      - ./maps:/data/maps
    command: >
      ros2 launch ugv_navigation navigation.launch.py
      map:=/data/maps/site.yaml

Use on Leo Rover and Raph Rover

Leo Rover uses an onboard Raspberry Pi compute unit and can run ROS 2 distributions supported by its operating-system and hardware configuration, including ROS 2 Humble where applicable. Docker can be used to deploy a reproducible ROS 2 workspace on that computer, for example a teleoperation node, a LiDAR driver, a SLAM application, or a Nav2 configuration. The container must be built for the processor architecture and operating system used by the onboard computer, such as ARM64 rather than x86_64.

Leo Rover has differential drive and requires an integrated autonomy stack before it can navigate autonomously. A container does not provide localisation, obstacle detection, or path planning by itself. It only packages the software that implements those functions and their dependencies.

Raph Rover can use the same deployment model when a project requires larger sensor payloads or additional compute hardware. For example, separate containers may run camera perception, RTK GNSS processing, rosbag recording, and navigation. Resource allocation should be measured on the actual onboard computer because CPU, memory, storage throughput, and GPU availability depend on the selected payload configuration.

Limitations and operational considerations

Containers improve software reproducibility but do not guarantee real-time behaviour. Scheduling latency still depends on the Linux kernel, CPU load, device drivers, middleware configuration, and competing processes. Safety-critical motor control should remain on the rover controller or another appropriately designed real-time subsystem, not depend solely on a best-effort container process.

Before deploying a container to a mobile robot, validate the following items on the target hardware.

  • Pin image versions by tag or digest to avoid unplanned dependency changes.
  • Use --device mappings instead of broad privileged access when possible.
  • Persist maps, calibration files, and rosbag data outside the writable container layer.
  • Confirm that DDS discovery works with the selected network mode and ROS_DOMAIN_ID.
  • Record image version, Git revision, ROS 2 distribution, and sensor-driver version for each experiment.

Normative references and technical sources

The following primary documentation defines the main technologies discussed in this entry.

See also