Graphical Turtles in Docker from Windows Subsystem for Linux

Let us take ROS2 for a quick spin. Docker makes it easy. Trying out software within a container often proves a useful approach. Containerisation saves time and effort in setting up. Undoing and erasing becomes a trivial wiping of a container—all true for ROS. Windows 11 loaded with Docker Desktop marks the starting point. Run the following Docker command from WSL, the Windows virtualisation subsystem for Linux. It only works if Docker enables WSL integration for the launching distribution¹.

docker run -it --rm --privileged -v /tmp/.X11-unix:/tmp/.X11-unix -v /mnt/wslg:/mnt/wslg -e DISPLAY -e WAYLAND_DISPLAY -e PULSE_SERVER -e XDG_RUNTIME_DIR osrf/ros:iron-desktop-full-jammy

OSRF stands for Open Source Robotics Foundation. “Iron” is the ROS distribution — the latest ‘stable’ at the time of writing.

These Docker run arguments summarise as follows.

• -it for an interactive session;
• --rm to remove the container on exit;
• --privileged for superuser access to X11;
• volume mounts:
  • -v /tmp/.X11-unix:/tmp/.X11-unix to map the X11 socket;
  • -v /mnt/wslg:/mnt/wslg to volume map the WSL graphics subsystem; and then
• environment variable exports:
  • -e DISPLAY for exporting the display address,
  • -e WAYLAND_DISPLAY for the name of the display socket,
  • -e PULSE_SERVER for connecting to the Pulse Audio server,
  • -e XDG_RUNTIME_DIR for the directory of the display socket; and finally
• osrf/ros:iron-desktop-full-jammy for the image.

Run the Turtle simulator. See below. The first ros2 run argument specifies the name of the package, the second specifies the package’s executable; any subsequent arguments pass to the executable’s argument vector.

ros2 run turtlesim turtlesim

It launches the turtle simulator from Linux running in Docker while operating the graphical front-end via Windows subsystem for Linux.

docker run -it --rm osrf/ros:iron-desktop-full-jammy

ros2 run turtlesim turtle_teleop_key

Rolling Ridley on Windows 11

Can a Windows 11 machine install Rolling ROS easily? The documentation makes it look hard, to install a chain of dependencies: Qt, OpenSSL, Python \(3.8\), etc.

A typical up-to-date Windows 11 machine has existing components that overlap and post-date ROS requirements. Can a developer install ROS2 ‘Rolling’ on Windows 11 with the latest version of Python \(3.11.x\) and nothing more? It differs from the ROS documentation’s directions. They want \(3.8\) Python on Windows 10 at least. But better if the ROS distribution accepts later stable versions. Does it still work? It does, as it turns out.

Run the following two PowerShell commands as Administrator.

choco source add -n=ros-win -s="https://aka.ms/ros/public" --priority=1
choco upgrade ros-rolling-desktop -y --execution-timeout=0

Chocolatey installs the necessary dependencies, e.g. vcredis2010 including Qt5 and other graphical tools and libraries. The resulting Rolling Ridley installs to C:\opt\ros\rolling\x64, including its own Python \(3.8.3\) binary. So although the documentation fails to mention it, Rolling on Windows 11 is more or less fully functional and easy to install using only Chocolatey.

Windows Terminal lets you launch a PowerShell console that automatically loads the local ROS setup. Include options -noe and -f with the local setup script as follows.

"C:\Program Files\PowerShell\7\pwsh.exe" -noe -f C:\opt\ros\rolling\x64\local_setup.ps1

Multi-Box

So far so good. Up to this point, the experimentation utilises just one Windows-11 box. The distinction between nodes running on one machine or two should make no difference in theory.

Doing the same thing on two different machines using ROS2 can fail however depending on their network interfaces. The underlying ROS middleware attaches to the first arbitrary network interface, e.g. a VPN network if you have one. ROS transports communication frames over UDP and that in turn requires an interface. Two, or more, disparate machines need to share communication routing with their interfaces meshed.

After no little digging, fiddling and head-scratching, literally for a while, the magic sauce amounts to first running in PowerShell:

$env:CYCLONEDDS_URI = "<CycloneDDS><Domain><General><NetworkInterface>Wi-Fi</></></></>"

The environment variable’s value encodes a nested XML string specifying “Wi-Fi” as the explicit network interface. Windows can set up the Cyclone URI in the user account’s persistent environment variables rather than setting it up every time at the command line. What does this say about ROS2? That the Rolling distribution uses Cyclone DDS by default but the environment can override those defaults.

The ROS2 doctor confirms the middleware and network interface; the ros2 doctor --report includes the snippet:

   RMW MIDDLEWARE
middleware name    : rmw_cyclonedds_cpp

Conclusions

ROS2 works well but involves many moving parts, not easy to uncover with an uphill learning curve. It nevertheless promises modular, scalable robotics applications without reinventing the wheel.

Salute you, Lao Tzu. Let the journey begin.