I’ve created a few Docker images for ARM [1], I thought it might be useful to someone, given that Docker works on ARM (e.g. Raspberry Pi). I got a Raspbian-based Raspberry Pi 3 running a Docker container for Xenial/Kinetic to control a Turtlebot.
@ruffsl@tfoote l I’d like to help them get merged into the official ROS repo. They depend on a base Ubuntu image I built myself [2], which is just the regular amd64 base image, but using these [3] as the root filesystem. What would be the best path to have these Docker images merged? I suppose tweaking the Docker templates would be enough and have them point to the Ubuntu image I built, but I’d rather transfer that to something more official (e.g. either Ubuntu’s or OSRF’s Docker repo)
We’re already building base docker images for all the non-standard arches that ROS supports here: https://hub.docker.com/u/osrf/ They are named ubuntu_[ARCH] or debian_[ARCH]
These are what we use as the basis for the buildfarm builds and tests on non-amd64 arches.
There’s some cleanup to promote the generic branch and probably rename the repo to not say 32bit since this script now generates amd64, armhf and arm64 builds of both ubuntu and debian. It evolved but since it’s a tool we use internally we haven’t taken time to clean it up.
For getting ROS builds based on those images into the docker registry our challenge is that we use the docker hub automated builds, and when I last looked into it they did not support building non x86_64 builds automatically. If that’s changed it would be great to extend the docker images to leverage the new support. But in general we don’t want to have to manually keep docker images up to date, or setup our own automation to build and upload images and maintain that automation. We know that Docker is talking about adding support for multi-arch and plan to wait for support to be added upstream.
I think OSRF has some automatic repositories for arm [1], or at least I started to consolidate for OSRF [2], but there probably have been upstream changes to the build process for the official 64bit ubuntu docker image since then as @tfoote mentioned. You may have seen @tianon from github may have pointed to those earlier [3].
I think the best thing to would be to investigate the state of arm support on Docker Hub, so that we could either utilize automated repos to build the images by building for an official arm ubuntu docker image, or see what are the current best hacks to provide this functionality for now. I know I’ve read about Resin.io doing somthing simalure [4], but I remeber talking to folks working from Docker.io about proposed offical support for this from last year, so I’ll fallow up with them to see if anything was anounced. Perhaps we could also reach out to Mano Marks, as he’s recently been active in this area [5]. Also, another set of folks to follow [7].
Perhaps this is putting the cart before the horse, but what tags would we want to provide? Would we want to provide tags for each meta package (e.g ros-core, …, ros-desktop), and then create septate repos for each architecture (e.g ros_arm:ros-core, ros_arm7:ros_core)? Or would we want to provide just say the ros-core image for each, and surve it under OSRF’s dockerhub profile (e.g. osrf/ros:arm, …, osrf/ros:arm7). Doing interdependent tags in one auto repo is still hard for non official library images [6]. Also, I’d imagin Docker.io may be working on another method of refrencing images/tags by archatecture, rahter than appending names with postfixes. We might want to ask about that too.
In terms of ARM containers on Docker Hub, I’ve successfully set up automated builds for ROS containers using the QEMU-based approach from the resin.io blog post that ruffsl referenced. See:
These are specific to the RPi3 (and do some non-standard things with Debian packages), but the approach works without these hacks. As long as the base image has the QEMU executable and scripts added (see GitHub repos linked from Docker Hub)
For posterity, if you find this and are still interested in docker images for ros on arm, you’ll be happy to find this:
Currently, for arm32v7, there is a blocking issue upstream with cloud image used in docker hub. If you would like to expedite arm32v7 support for ROS docker images, you may make your concerns know and follow the bug report: