Question: How to cross-compile custom ROS2 (foxy) package for Yocto Hardknott running on iMX8M-Mini SoC

[bojankoce]

Hello, guys!

I have a headache finding out what would be the most efficient way to develop the ROS2 application that will execute on a target machine (DART-MX8M-Mini SoM) running Yocto Hardknott - link.

My Host environment is Ubuntu 20.04. I can source from there the environment setup script provided by SoM manufacturer that will properly set the cross-toolchain (cross-compiler, sysroot...). More details here.

Also, meta-ros layer is bitbaked into the Yocto image.

Would it be possible for me to cross-compile the custom ROS2 package from my Host environment, generate binary executable and transfer it to the target machine running Yocto for testing/execution? If affirmative, what would be the steps to follow?

Thank you very much for your time and efforts. Looking forward to reading from you.

[shr-project]

More typical use would be to create a recipe for your custom ROS2 package in your integration metadata layer and build it with bitbake as all other recipes in meta-ros are built.

For better development experience you can use devtool https://docs.yoctoproject.org/ref-manual/devtool-reference.html which simplifies building inside OE development as well as deploying the binaries you want to test to target machine (and remote debugging with a bit of work as well).

Using separate cross-toolchain SDK should be possible as well, but depends on how it's set by SoM and there would be a lot of work on meta-ros side as well (to provide nativesdk extends where needed as well as making sure the environment set by SDKs environment script is correct - this is very fragile in OE environment already with ament searching native and target sysroots in a bit mysterious ways sometimes or python modules from target sysroot being used instead of native ones during build - in separate SDK this might get even worse to fix properly - I hope to eventually clean this when migrating ROS2 to use ros_opt_prefix like ROS1 does).

[bojankoce]

Hey, @shr-project !

Thanks for your feedback! The approach you described (create a recipe and build with bitbake) seems to be quite a time-consuming process. To the best of my understanding, every time I change a single line in my code, I would need to:

1. Rebuild the Yocto image
2. Burn the image on SD card
3. Boot the image on the target machine
4. Run desired binary of compiled ROS2 package.

Is my understanding correct?

I would need to explore deeply that devtool thing, I just entered into Yocto/ROS2 worlds!

[shr-project]

Yes, this is the scenario for devtool which will allow you to use OE build environment instead of SDK for fast development iterations (that you only rebuild the binary you're modifying and there is also helper to scp the built files to your target device) and only when you're happy with the results on target it will help you to update the recipe to use the modifications you've debugged and then you can continue with 1. 2. 3. 4. to create new target image.

So the most typical use-case for OE builds is to build images, but nothing prevents you to use the same build system and it's already prepared work directories for incremental development as well.

[bojankoce]

Hello, @shr-project!

I properly added meta-ros layer and ROS2 foxy distro to our Yocto build by following instructions from here (Sanity Tests pass successfully).

I wanted to use a devtool and build a simple custom ROS2 package containing publisher and subscriber nodes. The source code of the package is on the git - link.

I used tips and tricks from here to create ROS2 recipes with devtool. My custom bitbake recipe for the simple ROS2 package looks like this (my-first-yocto-pkg_git.bb file):

DESCRIPTION = "Example of minimal publisher/subscriber using rclcpp."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://package.xml;beginline=8;endline=8;md5=3a75fd635766e2f76c3d90ee6495f310"

SRC_URI = "git://github.com/bojankoce/ros2pkg;protocol=https"

# Modify these as desired
PV = "0.1.0"
SRCREV = "1312445de2e6861d9561c0f89f4827b94c2ff6b1"

DEPENDS = "rclcpp std-msgs"

S = "${WORKDIR}/git"

# NOTE: unable to map the following CMake package dependencies: rclcpp ament_lint_auto std_msgs ros_ament_cmake
inherit ros_ament_cmake

However, when I tried to build the package with devtool build my-first-yocto-pkg command, I get the following error:

CMake Error at CMakeLists.txt:19 (find_package):
  By not providing "Findament_cmake.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "ament_cmake", but CMake did not find one.

  Could not find a package configuration file provided by "ament_cmake" with
  any of the following names:

    ament_cmakeConfig.cmake
    ament_cmake-config.cmake

  Add the installation prefix of "ament_cmake" to CMAKE_PREFIX_PATH or set
  "ament_cmake_DIR" to a directory containing one of the above files.  If
  "ament_cmake" provides a separate development package or SDK, be sure it
  has been installed.

The issue is around ament_cmake. I included the inherit ros_ament_cmake line into the recipe but this does not help. Do you have any idea about what I am missing here?

Thanks in advance for your time and efforts.

Cheers,
Bojan.

[amamory]

late reply, but for future references.

I am not an ROS/Yocto expert but I can share the path that work for me, without much effort.

I tried to use meta-ros itself as a reference. So i looked for the simplest recipe i could find. Eventually i found this one https://github.com/ros/meta-ros/blob/zeus/meta-ros2-foxy/generated-recipes/demos/dummy-sensors_0.9.3-1.bb that worked fine for my 1st ROS2 Yocto recipe. After the 1st one works, you can keep doing a similar approach, which means finding a similar recipe to the one you want o create.

I hope this can help ....

[bojankoce]

Thanks, @amamory ! This is the exact strategy I am applying myself. 👍

Cheers, Bojan

[SergeyFabric]

@shr-project Hi, do you know if there some news on SDK development? I working with couple of programmers at the same time so we need the SDK for a better workflow.