Simplifying ROS 2 embedded flows with colcon extensions

General
, , ,
1

For those of you dealing with embedded hardware in robots on a usual/daily basis, you’ll probably know how cumbersome and time consuming it sometimes becomes. Specially if you have more than one embedded targets.

In an attempt to simplify some of these embedded flows while aligning with ROS 2, we’ve contributed at colcon-acceleration various extensions for colcon-core to include capabilities to navigate across firmware options in a workspace, customize the Linux kernel, create Xen hypervisor configurations and associated partitions, extracting ramdisks, and more. This can save you minutes, hours (or even days) depending on your familiarity with some of these embedded aspects.

Though these contributions have been made with hardware acceleration purposes in mind, the extensions themselves could be reused by other groups within the community. Pinging the Real-Time WG guys (@carlossv, @LanderU) or the Embedded WG (@mamerlan), among others. Here’re some of the current capabilities:

verb quick peek description
select asciicast The select verb allows to easily select and configure a specific target firmware for hardware acceleration, and default to it while producing binaries and accelerators.
list asciicast The list verb allows to inspect the acceleration firmware available in the ROS workspace, marking with a * the currently selected option.
linux asciicast The linux verb helps configure the Linux kernel in the raw SD card image produced by the firmware. E.g. colcon acceleration linux vanilla will produce a Linux vanilla kernel, whereas colcon acceleration linux preempt_rt will instead use a pre-built kernel and kernel modules for improved determinism (fully preemptible kernel).
hypervisor asciicast The hypervisor verb helps configure the Xen hypervisor in the raw SD card image produced by the firmware. E.g. colcon acceleration hypervisor --dom0 vanilla --domU vanilla --dom0less preempt_rt will produce a raw image leveraging Xen with 3 VMs. The first, dom0, uses a vanilla kernel. The second, domU, uses a vanilla kernel. The third is a dom0less VM and uses a fully preemtible kernel (preemt_rt). Unless otherwise specified, all VMs use the default ROS 2 configuration, PetaLinux-based rootfs, the LNS and an Ethernet link layer.
emulation asciicast The emulation verb helps manage the emulation capabilities with QEMU open source machine emulator and virtualizer. This way, developers can test their setups and algorithms without the hardware, which facilitates testing and speeds up the development process allowing for CI/CD pipelines. Emulation boots the same SD card image produced by previous commands and including the ROS 2 development workspace, providing a unified development approach.
platform asciicast The platform verb helps reports Vitis platform enabled in the firmware deployed in the ROS 2 workspace.
mkinitramfs asciicast The mkinitramfs verb creates compressed cpio initramfs (ramdisks). These can then be used to back up the current rootfs or to create dom0less VMs in Xen easily.
mount / umount asciicast The mount and umount verbs help mount/umount the raw SD card image produced by previous steps. This way, developers can easily access the embedded rootfs directly, across the various partitions of the raw image (e.g. as in the case of multi-VMs in Xen).

We’re also looking for feedback on what other (embedded) things the community is missing when developing with their boards. Some of the aspects being considered include network booting of multiple embedded targets (which is cool if you have a multi-board/SOM robot) and simplified security additions and configurations for embedded. Are there any asks out there that we should consider?

7 Likes
2

With respect to Qemu emulation what is the best source to find examples tutorials using ROS2?

3

The best example I know to get started is this one. I would recommend, nevertheless, to look at all those examples in order, as they were built so that people could dive into this incrementally:

  1. ROS 2 publisher
  2. Hello Xilinx (here’s the first intro to the use of emulation for hardware)
  3. HLS in ROS 2
  4. Offloading a ROS 2 publisher
  5. Accelerated ROS 2 publisher
  6. Faster ROS 2 publisher

You can run all the examples in emulation, instead of with the real hardware. Note that Xilinx offers three build targets for its Vitis compiler (v++), the first two leverage emulation (QEMU):

  • Software Emulation ( sw_emu ): The kernel code is compiled to run on the host processor. This allows iterative algorithm refinement through fast build-and-run loops. This target is useful for identifying syntax errors, performing source-level debugging of the kernel code running together with application, and verifying the behavior of the system. Simply put, a transformation which runs all the code in an emulated processor matching the K26 SOM, as if there wasn’t any accelerator .
  • Hardware Emulation ( hw_emu ) - The kernel code is compiled into a hardware model (RTL), which is run in a dedicated simulator. This build-and-run loop takes longer but provides a detailed, cycle-accurate view of kernel activity. This target is useful for testing the functionality of the logic that will go in the FPGA and getting initial performance estimates. In other words, a simulation within an emulation. The FPGA is simulated and runs inside of an emulation (QEMU), sitting together to emulated processors and allowing to get performance estimations faster .
  • Hardware ( hw ) - The kernel code is compiled into a hardware model (RTL) and then implemented on the FPGA, resulting in a binary that will run on the actual FPGA.

Note the emulation verb above allows you to do this directly from the colcon extensions contributed:

colcon acceleration emulation -h
usage: colcon acceleration emulation [-h] [--no-install] [--mixin-files [FILE [FILE ...]]]
                                     [--mixin [mixin1 [mixin2 ...]]]
                                     [emulation_type] [install_dir]

Manage emulation capabilities.
Vitis offers two emulation targets for development, debugging and validation purposes.

positional arguments:
  emulation_type        Emulation of board with either PL software simulation ("sw_emu" key) or
                        PL software emulation ("hw_emu" key).
  install_dir           relative path to the workspace directory to deploy in emulation
                        (typically 'install-*').

optional arguments:
  -h, --help            show this help message and exit
  --no-install          Do not copy install_dir (or default) to second partition

Mixin predefined sets of command line parameters:
  --mixin-files [FILE [FILE ...]]
                        Additional files providing mixins
  --mixin [mixin1 [mixin2 ...]]
                        No mixins are available for this verb

In other words, you can do something like:

colcon acceleration emulation sw_emu  # for sw_emu
# or
colcon acceleration emulation hw_emu  # for hw_emu

Of course, for kernels to be run in this emulated environments, you need to build them with the right flags. This is simplified and integrated into the ament extensions proposed. You can configure this directly in the kernel definition within the CMakeLists.txt of each ROS 2 package. See this example.

If after all of this, you still want to dive deeper, then the following resources will be helpful:

1 Like
4

Thank you for the detailed response! I’ll work my way through the tutorials.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.