It would be nice to include in the repository some subdirectories for the most common platforms, containing scripts for creating a sysroot and cross-compiling.
I think that this is the biggest lack of the current tutorial: the provided instructions are easy to translate to other architectures as long as you don’t use a sysroot.
In any case I will be happy to contribute to this new repository!
EDIT: I just noticed this post from the ROSCon meetups
I agree as well. It would be so nice if there were a general guide to “cross-compile ROS2” for other platforms (RTOS as well).
I’m searching something on web about this topic but I found the same links which you already presented.
Could you let us know? thank you so much
I’m almost done with the tutorial page. I add some general information about CMake and cross-compilation.
I’m still thinking on the best way to upstream the cross-compilation related files. The last idea is to create a ros2/crosscompile repo, which will contains a package with the same name.
This repo will come by default with a COLCON_IGNORE, allowing us to add it to the ros2.repos file. Native compilation will not be affected, and cross-compilation would be possible by simply removing this file.
This approach allows us to add a script to generate the sysroot with colcon, before the other packages.
Regarding the cross-compilation itself, I still have to ignore the following packages:
@Silvia, I think support for RTOS is a more complicate topics than just cross-compilation. You will probably find more info on this if you look for “embedded ROS2” topics, like this one ROS2 Embedded SIG meeting #1
Could we have an example of cross-compiling an application against a pre-built ROS2 (for example, to cross-compile https://github.com/ros-perception/vision_opencv without having to cross-compile ROS2 along with it)?
@Silvia, @lmayencourt, We have created and implementation of the rmw layer using Micro XRCE-DDS, a middleware specific for microcontrollers. Regarding the cross-compiling topic here I think you may want to check how we cross-compile part of the ROS 2 stack into an STM32, using an RTOS like NuttX.
The RTOS and cross-compilation interesting parts are in this repository (Following NuttX way):
@BorjaOuterelo I can’t find a .cmake file to cross-compiling ROS2 in NuttX in your microROS/apps link. Is there? how do you perform the cross-compilation?
Please, have a look at the first version of the cross-compile repo.
Note that this is a temporary location for the repo ! We want to move this under ros2/cross-compile.
The following PR add the documentation and the repo to ros2.repos:
Hi @lmayencourt, I finally had time to look at the repository and the instructions. They look great!
However I noticed that you are still targeting Bouncy repositories.
Have you tried cross-compiling Crystal repositories using that same instructions?
I’m asking because I have created a similar framework, which should allow me to cross-compile for Bouncy as well as for Crystal.
However, even if the build phase goes fine in both cases, I get a Bus error when running any of the Crystal example executables.
Hi @alsora,
Thanks for taking the times to look at the repo+instructions !
I’m facing some issues when cross-compiling Crystal and I would be interested to see the differences you have in your setup that allows you to pass the build.
On my last try, qt_gui_cpp was failing and after that rosidl_python…
@clalancette Thank you, that fixed the error perfectly.
@lmayencourt I’m currently ignoring all the visualization packages.
After Christmas I will try to cross-compile also these packages for RaspberryPi and I will let you know how it goes.
Hi,
I’m now able to cross-compile the full Crystal release apart of ros-visualization and rviz packages !
I’m trying to find the issue with rviz and I will try the same with ros-visualization if I have the time.
I have done a few updates on the cross-compilation assets:
rviz (master) can now be cross-compiled
a generic dockerfile is used to generate an aarch64 or armhf file-system. A build argument can be specified to docker:
- armhf: docker build --build-arg ARM_ARCH=arm32v7 …
- aarch64: docker build --build-arg ARM_ARCH=arm64v8 …
the target docker container is cleaned after been extracted