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

emersonknapp · 2019-12-03T00:13:51.733Z

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!

rreignier · 2019-12-03T15:01:23.170Z

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

dirk-thomas · 2019-12-11T20:13:54.054Z

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 (with the advantage of always being up-to-date).

theseankelly · 2020-01-27T16:58:58.571Z

Thanks for publishing this! I recently went through the exact same process to get ROS2 dashing running on an OpenEmbedded-based i.MX6 device, and came down to a very similar set of workarounds and subest of repos.

I would find an officially curated variant very useful. Do you plan on submitting a proposal per Dirk’s suggestion? Happy to help if you want.

emersonknapp · 2020-01-29T23:14:44.485Z

Yeah, I am working on a REP-2001 proposal. It hasn’t been very fast going but it’s definitely still on my mind. I’ll make sure to put up a PR by the end of the week. I think there will be a few open questions to resolve, but probably better to put something out there and start the conversation

emersonknapp · 2020-02-04T01:27:27.294Z

Not quite by the end of the week, but here’s a first shot at proposing this variant. https://github.com/ros-infrastructure/rep/pull/231 - conversation and feeback please!