Skip to main content
The robotics image is the operating system deliverable of the QIR SDK. It is a distinct Qualcomm Linux product: it is built with its own Yocto distribution, its own meta layer, its own kernel configuration and device-tree patches, and its own image recipes. It is not the stock Qualcomm Linux (QLI) 2.0 image with a few ROS packages added.
You cannot take a stock QLI 2.0 image and “just add the robotics overlays” to it. The robotics image is a different distribution, kernel, device tree, overlay configuration, and meta layer. The build-time changes required to reproduce it are listed in Why you cannot just add the robotics overlays below.

​
How the robotics image differs from a stock QLI 2.0 image

The differences are structural, not additive: You can confirm the running distribution on a flashed device:

​
Two robotics image recipes

The QIR SDK provides two image recipes, each built with a different Qualcomm Linux overlay configuration. Overlays are the modular, value-added Qualcomm technology stacks (camera, video, audio, graphics, sensors, vision) that integrate with the upstream components, letting you choose between the upstream and the Qualcomm technology stacks. For the overlay mechanism itself, see Use overlay configurations to derive image recipes.

​
Why you cannot just add the robotics overlays

A robotics overlay is not a drop-in package set you install onto a finished root filesystem. Reproducing the robotics image requires all of the following at build time:
  1. Add the meta-qcom-robotics-sdk layer (clone tag qli-2.0) and drive the build with KAS. The stock multimedia KAS fragments do not include it.
  2. Switch the distribution to qcom-robotics-distro / qcom-robotics-ros2-jazzy, which pulls the ros2-jazzy feature into DISTRO_FEATURES. A stock qcom-distro build has no ROS distribution feature.
  3. Select a kernel provider and accept the robotics kernel changes. The layer’s recipe-kernel bbappends add kernel config fragments and device-tree (DTS) patches, and you choose linux-qcom-6.18 or the real-time linux-qcom-rt-6.18. This re-patches the kernel and device tree, which cannot be achieved by installing packages onto a prebuilt rootfs.
  4. Build the correct image recipe with the matching overlay config, then enable the overlays on the device. Device-side enablement includes driver-module blacklisting and, for the camera, setting the VendorDtbOverlays EFI variable to camx. See Overlay functionality and driver module blacklisting.
  5. Pull in the ROS 2 stack and its adaptations: ROS 2 Jazzy plus the qrb-ros, Navigation2, MoveIt, and Cartographer recipes and .bbappend adaptations that a stock image neither declares nor builds.
For the underlying platform, kernel, and device-tree changes in Qualcomm Linux 2.0, see Changes in the Qualcomm Linux kernel.

​
How to get the robotics image

Flashing the prebuilt robotics image is the fastest and recommended path.

​
Build it yourself (optional)

Rebuilding the QIR SDK is complex and is not required for most developers. Prefer the prebuilt image or the prebuilt eSDK unless you need to customize the image.

​
Migrating from Qualcomm Linux 1.0

If you are moving from a Qualcomm Linux 1.0 robotics build, the distribution, layers, and image-composition model all changed.