There seems to be a lot of interest in using ROS on Raspberry Pis. The solutions that I have seen so far are either to compile ROS manually for Raspbian, which is not straightforward, or to just use Ubuntu on Raspberry Pi 2 or 3.
However, Raspbian still provides the best support for all Raspberry Pi versions, including version 1 and Zero, and I think that officially supporting Raspbian by providing Debian packages would help a lot of people to get started with ROS on Raspberry Pi.
What are the blocking issues that prevent the build farm to build Debian packages for Raspbian Stretch? The only issue I see are the drivers for low-level camera and media-codec access, which are not available on other distributions. Apart from this, Raspbian Stretch contains all necessary packages to build the full ROS desktop stack.
Specifically to your question I do not believe that there are any blockers for supporting Raspbian Stretch. For ROS purposes it’s basically the same as Debian Stretch. And we have built packages for raspbian in the past too.
Targeting all the way back to Raspberry Pi 1 is noteably harder as it does not fully support the armv7 architecture and you must compile armv6+vfp2 or target the slower armel(armv6) instruction set. Setting up infrastructure to support that very specific hardware would be non-trivial. In the past I know that people have actually resorted to building packages natively on the rapsberry pi. And some packages took close to a week to compile. This would require a very large cluster and a lot of maintenance and supervision that I would not recommend.
We have general support for armhf(armv7) and aarch64(armv8) builds on the build farm as well as support for both Debian and Ubuntu. The buildfarm can be configured to support the full matrix of architectures, distros (both Debian and Ubuntu). However if we turned on all of those architectures it would take a lot more computation time as well as monitoring and maintenance to keep track of the builds. In the past we’ve supported as many as 8 simultaneous architecture/distro combos for a single rosdistro and with our overlapping rosdistro support cycles we can end up with quite a few. (For example we’re currently building for 18 at the moment. Across Indigo, Kinetic, Lunar, and Melodic) If we supported the full matrix, 13 distro/rosdistro targets across 4 architectures, we would be building more than double the buildfarm size. And the arm builds incur extra costs as they either need to be run in emulation or on separately maintained ARM based servers. The emulated builds take close to 10x as long as x86 builds which also incurs more costs.
The main reason that we are not building armhf for stretch is resource availability. There is both a direct cost of running the computers as well as maintenance and monitoring of the buildfarm and all the computational resources it uses. As well as release management and build failure tracking. In the interest of being efficient with our available resources instead of trying to build all targets we choose to pick a spanning set that will cover as many users as possible with the resources we have available.
You can find the targeted distros are recorded in REP 3 and we review trends in the computers we see people using as well as our collected metrics to prioritize which distro-arch combinations to target.
Related to the Rasbperry Pi we specifically made sure that we had at least one armhf target that would be able to run on the Raspberry Pi. The Ubuntu Xenial armhf which is a commonly used image for the Raspberry Pi. These same packages can also be used on all other armhf boards the support Ubuntu instead of only working on the Rasbperry Pi which is why we picked the generic Ubuntu target rather than the more specific raspbian target.
If you have a specific use case and want to just support local needs, building your own packages is possible. In developing the build farm infrastructure we have worked hard to make sure that what we do on build.ros.org is reproducable by the community. If you start here: http://wiki.ros.org/buildfarm there’s full documentation of how to setup and run your own buildfarm and if you do so you can pick the architectures of your choice. We did this to allow support for specific use cases where a project wants to have a specific potentially non-standard target so that they can do a localized effort instead of needing to ask for specific support on the main buildfarm for a smaller use case.
As an aside, with additional support Open Robotics can enable more architectures on the main buildfarm. If anyone would be interested in sponsoring support for a specific platform please contact me directly.