Abdullahi Mohamed // Engineering Home Base

In robotics development, environment consistency is a major pain point. Installing ROS2 (Robot Operating System 2) manually often involves hundreds of dependencies that can easily break your host system. I built this tool to provide a "one-click" isolated workspace that doesn't sacrifice GUI performance.

The Origin Story

I was so frustrated with the brittleness of manual ROS2 setups that I wanted to see if I could automate the configuration of X11 forwarding and Wayland sessions. It usually breaks GUI tools like RViz2 or Gazebo inside a container because they can't access the host's display server.

Building a refined set of Bash scripts and Docker configurations allows me to launch a functional environment with one command across Linux, macOS, and Windows.

Bash Automation: The CLI is a set of modular Bash scripts that check for Docker and X11 dependencies before launching.
X11/Wayland Integration: We map the host's /tmp/.X11-unix socket and the XAUTHORITY file to the container.
Persistent Development: The tool mounts your local workspace to the container, so you can code on your host (e.g., using VS Code or Neovim) while running the build inside the container.

The Nvidia Struggle

The core challenge was getting the container to talk to the host's display server without compromising security. I spent a few late nights just trying to figure out which environment variables to set so things wouldn't flicker.

# Docker Compose logic for X11 Forwarding
services:
  ros2:
    build: .
    image: robot:latest
    container_name: ros2
    volumes:
      - .:/home/src
      - /tmp/.X11-unix:/tmp/.X11-unix:rw
      - ${XAUTHORITY}:${XAUTHORITY}
    environment:
      - DISPLAY=${DISPLAY}            # Handle X11 or XWayland
      - WAYLAND_DISPLAY=${WAYLAND_DISPLAY}  # Handle Wayland sessions
      - QT_QPA_PLATFORM=xcb           # Explicitly use XCB for Qt apps
    command: bash && colcon build

Lessons Learned

I initially struggled with ROS2's DDS (Data Distribution Service) discovery inside Docker. I had to learn how to properly configure the network mode to host in certain cases to ensure that different containers could communicate with each other just like real robots on a network.

I'm thinking about adding a pre-configured simulation hub for Gazebo and Ignition, and maybe adding Docker Compose profiles so users can define multiple "robot" setups for multi-robot simulations.