ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

C/C++ minimal source-tree-only ROS2 variant?

I’ve been working on producing a ROS2 build for a custom SBC (aarch64) platform and have found that with the latest tree, I am able to carefully produce a build for this custom distro, with no external rosdep dependencies, using the Linaro cross-compiler.

The build should be perfectly reproducible using the README from the following: https://github.com/emersonknapp/ros2-toolchain-crosscompile

Some features of this build:

  • Using cyclone DDS - because no asio external dependency
  • disabling log4cxx and just relying on spdlog
  • rclcpp only
  • No python, therefore no CLI

The install folder comes out to ~80MB, which is fairly reasonable for lots of SBCs

This is extremely promising for the “minimal-but-still-Linux” compute use case.

My question is, (maybe largely directed @dirk-thomas and/or @tfoote ), does OpenRobotics also see the value in pursuing this highly limited variant, for allowing users to plug in their own compilers and sysroots, and run ROS2 on their resource-limited boards? The CLI, python client, GUIs, etc, can still all be used from the developer’s machine, but not on the target robot, which seems like a plus for a lot of use cases.

If so, what would we call it? Since “core” is taken. Perhaps “minimal”? “Core” could then build on top of “minimal”, keeping the upstream variants intact.

This variant would probably be more source quality control than binary distribution, since the target device distributions may not (mine doesn’t) have a package manager. The user would gain some guarantee that the source within the scope of “minimal” has no external dependencies outside a few select common linux libraries (thinking zlib, openssl specifically)

It seems like it wouldn’t be too hard to set up a CI job for this target variant and ensure it keeps working at least for a “vanilla linaro aarch64 sysroot” situation, if such a thing was desired.

Let me know what you think!

5 Likes

Oh, this looks nice!
It should enable the use of ROS 2 on minimal embedded systems built with Buildroot.

1 Like

I would suggest to propose a ROS variant for this in REP 2001. The content of the variant should be described in words with a rational why some packages are included while others are skipped. Based on that rational it might be easier to settle on a name for that variant.

A repos file isn’t needed imo then since the variant should be mapped to a metapackage and the set of packages can be collected using that with the help of rosinstall_generator.