Skip to main content
qrb_ros_transport is a zero‑copy ROS 2 transport for Qualcomm robotics platforms. It’s implemented on top of REP 2007 (Type Adaptation), which lets a ROS node declare that a custom message type is interchangeable with a standard one — so the middleware can hand off the DMA‑buf file descriptor that the camera ISP wrote instead of serializing and copying the pixel payload. In the stock path every subscriber receives its own copy of the frame, and every copy is a CPU memcpy. In the QRB path the producer and all consumers share the same DMA buffer — the fd is what travels through the ROS graph, not the pixels.

​
Supported adapted types

QRB adapted typeStock ROS interface
qrb_ros::transport::type::Imagesensor_msgs::msg::Image
qrb_ros::transport::type::PointCloud2sensor_msgs::msg::PointCloud2
An Imu adapted type also exists upstream, but producing data through it requires qrb_sensor_client + the specific ICM-42688 IMU on the RB3 Gen2 kit. If you have that exact hardware, see qrb_ros_imu. For typical use cases the bandwidth case lives in Image and PointCloud2 — IMU payloads are tiny enough that zero-copy adds little.

​
Supported targets

Hardware
Qualcomm Dragonwing™ IQ‑9075 EVK
IQ‑8275 EVK is not currently listed by the upstream qrb_ros_transport README. Check the upstream repo for the latest supported targets before building.

​
Vs. stock image_transport

Stock image_transport / sensor_msgs::Image always serializes the payload into the ROS message and copies it into each subscriber’s buffer. That’s fine for small topics and CPU-resident data, but it’s wasted work when the producer is a hardware block that wrote the frame into DMA memory (the camera ISP is the common case) and the consumer is another hardware block (GPU for color conversion, NPU for inference, EVA for computer-vision ops). qrb_ros_transport exists specifically for that hardware‑to‑hardware case — the pixels stay in DMA memory, and only the fd moves. If both ends of your topic are CPU code, stock image_transport is fine and simpler. The zero‑copy win scales with (payload size × number of subscribers × number of node boundaries crossed).

​
Installation

These steps require Qualcomm Ubuntu and ROS 2 Jazzy. Start from Install Ubuntu on Qualcomm IoT Platforms and Install ROS Jazzy if you haven’t already. For Qualcomm Linux, use the QIRP SDK instead.
1

Add the Qualcomm IoT PPAs

sudo add-apt-repository ppa:ubuntu-qcom-iot/qcom-ppa
sudo add-apt-repository ppa:ubuntu-qcom-iot/qirp
sudo apt update
2

Install the Debian packages

sudo apt install ros-jazzy-qrb-ros-transport-*

​
Usage

Add the adapted type as a dependency and write against it the same way you’d write against any typed ROS message — the middleware handles the rest. 
<depend>qrb_ros_transport_image_type</depend>
Install the development dependencies:
sudo add-apt-repository ppa:ubuntu-qcom-iot/qcom-noble-ppa
sudo add-apt-repository ppa:ubuntu-qcom-iot/qirp
sudo apt update

sudo apt install ros-dev-tools \
  ros-jazzy-lib-mem-dmabuf \
  ros-jazzy-qrb-sensor-client \
  ros-jazzy-pcl-conversions
Clone and build with colcon:
source /opt/ros/jazzy/setup.bash
git clone https://github.com/qualcomm-qrb-ros/qrb_ros_transport.git
colcon build
qrb_ros_transport sits on top of two upstream packages in the same org:You don’t interact with either directly when using qrb_ros_transport — they’re pulled in transitively. The pointers are here for readers who want the full stack or who need to port code to non-Qualcomm Linux SoCs with DMA-heap support:
  • dmabuf_transport — portable REP 2007 adapted types for Image and PointCloud2. Works on any Linux 5.12+ SoC with a DMA heap.
  • lib_mem_dmabuf — the userspace C++ DMA-buf allocation library. Use directly only if you’re doing non-ROS interop (GStreamer, V4L2, custom drivers, OpenGL ES).