KRS Unleashed: 1) Getting Started

The Kria Robotic Stack (KRS) is a superset of the Robotics Operating System (ROS 2) developed by the Hardware Acceleration Working Group (HAWG). It was originally developed by Xilinx/AMD for their Kria SoM family to bring hardware acceleration into the robotics ecosystem by integrating their Vitis Unified Toolchain into ROS 2. Articles have been published on how to use KRS and realize first projects with FPGA Robotics like the series by Whitney Knitter.

However, recent development of KRS has fallen short and more complex scenarios are not existent. The KRS Unleashed is an architectural revision of the original Kria Robotics Stack (KRS) focusing on relaxing the dependencies between internal components and providing a more slim, easier to extend environment. Further components have been added to underline these improvements. See the [paper](add link) for further information.

I am the author of the KRS Unleashed framework and want to use this series to document the intended workflow.

KRS Unleashed - Overview

KRS Unleashed separates the original single workspace, which was nice to get started, into 3 separate spaces to ease parallel development:

• 1. OS (Operating System) Workspace
• 2. KRS/ROS 2 Workspace
• 3. Vitis Workspace

Generally speaking, when designing a FPGA robotics application, many different components have to be developed and integrated to form the whole HW/SW Codesign system.

OS Workspace

As ROS 2 is a rather extensive framework, OS support including a full network stack is required on the board. The dependencies for ROS 2, FPGA support and the user application must be installed and a cross-compilation toolchain against the sysroot created.

An OS for the Kria SoM requires an extensible platform design (XSA) describing potential interfaces for later hardware accelerators, clock signals,.. The original KRS flow relied on an Ubuntu OS that already was based on an non-changeable XSA.

Ubuntu 22.04 and 24.04 are a great choice for ROS 2 development, as these are also the primary distributions ROS 2 is shipped with, reducing dependency problems to a minimum and providing developers with a familiar environment.

Commercial usecases however, could be interested in more sophisticated systems based on Embedded Linux/Petalinux to harden a system and reduce the jitter. Similarly, support for custom boards and custom XSA's was limited in the original flow.

The new OS Workspace contains the necessary setup to create an SD Card Image and prepare a sysroot environment for cross-compilation. The original Ubuntu flow was extracted into a simple callable script. Additionally, a script for a Petalinux flow was added, which requires an XSA and a bsp file.

Details on how to use this flow will be provided in the next article.

KRS/ROS2 Workspace

This module was primarily simplified and extended with tracing capabilities. The current core workspace contains only 5 packages with very lightweight dependencies to the other workspaces. The commands to build projects are the same as in KRS, but it was made more configurable to support further firmwares. The removal of the firmware creation and HLS also drastically speed up the compilation times.

Details on the KRS Workspace will be provided in article 3.

Vitis Workspace

The Vitis Workspace is a completely new flow replacing the old, implicit HLS. While it was nice at first glance to directly synthesize kernels in ROS 2, development of such kernels was tricky. Almost no feedback of errors, no helpful testing, syntax highlighting,.. meant that this flow was intended only to synthesize known-to-work kernels after their development.

Instead, we developed a scripted Vitis Workspace flow which automates based on the new Vitis Python API clicks inside the GUI to create Platform, HLS, Software and System components, configures, builds and connects them and bundles the final artifacts inside an export_folder. Because the flow is fully based around the Vitis Workspace concept, users can simply open the workspace in Vitis Unified at any point in time, debug, analyze or manually interact with it.

Details about this process will be explained in article 4.

Integration and Deployment on the Board

The final article 5 will then explain on how to develop applications starting in SW, adding kernels to it, cross-compiling it, analyzing some traces and putting everything onto the board.