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!