How to build and deploy AI robots on Qualcomm Dragonwing

Open-source ROS 2, on-device NPU inference, and a straight line from your laptop to a production robot, all anchored on the Qualcomm Dragonwing.

Why this is a good time to build robots on Qualcomm

The robotics stack is public, open source, and built to take you from a ROS 2 prototype on your laptop to a production deployment on Qualcomm Dragonwing hardware.

Qualcomm's robotics stack is built on open ROS 2 Jazzy packages, ships under BSD-3-Clause, and installs from public PPAs. You can pull an already-quantized model off Qualcomm AI Hub, drop it into a ROS node, and watch it run on the Hexagon NPU without leaving the ROS graph you already know.

With both the Qualcomm Dragonwing IQ-9075 EVK and the IQ-8275 EVK, you get Ubuntu running ROS 2 Jazzy, a dedicated NPU capable of delivering high TOPS performance for AI workloads, and multiple MIPI CSI camera ports. These platforms feature an industrial-grade thermal envelope, making them robust options for autonomous mobile robots and industrial automation, while remaining accessible enough for prototyping on a bench. Both are available for evaluation today and serve as reference targets for the open packages discussed in this overview.

The open stack at a glance: Qualcomm Intelligent Robotics SDK and Qualcomm Robotics ROS

Two names come up constantly, so let us make them crisp.

Qualcomm Intelligent Robotics SDK (QIR SDK) is the unified entry point for the Robotics SDK. "QIR" is the product brand of the Robotics SDK. It gives you reference ROS packages, end-to-end sample applications, a cross-compile toolchain (aarch64-oe-linux-gcc, make, cmake, ROS core), and the tooling to build customized images.

Qualcomm Robotics ROS (QRB ROS) is the open-source window of QIR SDK, the part that stays in direct contact with the OSS and upstream community. It is Qualcomm's upstream collection of ROS 2 Jazzy packages, published at github.com/qualcomm-qrb-ros under BSD-3-Clause.

The key thing to internalize: these are not two competing efforts. QIR SDK consumes the QRB ROS source and delivers it at L4 quality on Qualcomm Linux  (1.0 and 2.0) and on Canonical Ubuntu. Same source, two public paths. You can live entirely in the open QRB ROS repos, or you can consume the same components packaged through QIR SDK, and they line up.

Concept	What it is	Where it lives
QIR SDK	Unified entry point and product brand of the Robotics SDK	QIR SDK documentation
QRB ROS	Open-source window of QIR SDK, ROS 2 Jazzy packages, BSD-3-Clause	QRB ROS GitHub repo
Distribution	Public Qualcomm IoT PPAs	ppa:ubuntu-qcom-iot/qcom-ppa, ppa:ubuntu-qcom-iot/qirp

The QRB ROS packages worth knowing

Package	What it gives you
qrb_ros_nn_inference	Load a .tflite / .so / .bin model from AI Hub and run it on the Hexagon HTP NPU from a ROS 2 node
qrb_ros_transport	Zero-copy DMA-buf transport that passes a file descriptor instead of memcpy-ing Image and PointCloud2 payloads
qrb_ros_samples	Reference pipelines: detection, segmentation, pose, depth, plus Nav2, AprilTag, and pick-and-place
qrb_ros_simulation	Gazebo evaluation with prebuilt AMR and manipulator configs, so you can try it without a board
qrb_ros_benchmark	Apples-to-apples benchmarking of the zero-copy path against stock sensor_msgs
ROS2-DDSConfig-Optimizer	An LLM-driven FastDDS QoS auto-tuner that works on any ROS 2 setup

Choose your level of abstraction

One of the nicest properties of this stack is that you are not forced to pick "Qualcomm samples" or "stock ROS." The primitives compose, and all three levels target the same silicon and interoperate on the same ROS graph.

Pick the level of wiring that fits your goal:

Level	What you use	Good when
From scratch	QNN delegate + stock ROS 2 + an AI Hub model, wired yourself	You want full control of the pipeline and understand every hop
Generic NPU node	qrb_ros_nn_inference + your own AI Hub model	You want drop-in NPU inference on any topic without hand-rolling QNN
Reference pipeline	A qrb_ros_samples entry, as-is or lightly modified	You want a working perception stack now and will swap parts later

 

Two call-outs make all three levels fast on Qualcomm hardware:

 

- NPU inference on the Hexagon HTP. qrb_ros_nn_inference loads a model artifact and runs it directly on the NPU from inside a ROS 2 node. That is the accelerator path you want for real-time perception.

- Zero-copy transport. qrb_ros_transport is built on REP 2007 Type Adaptation, so the frame the camera ISP wrote stays in DMA memory and only the file descriptor travels through the ROS graph. The win scales with payload size, number of subscribers, and number of node boundaries crossed, which is exactly the hardware-to-hardware camera-to-NPU case in robotics.

Whichever level you pick, the model that feeds it comes through the same lifecycle: get it optimized, get it onto the device, keep it running fast and local once it is there. That is what AI Ops means for a robot, and every step of it is public tooling you can use today.

Most paths start at Qualcomm AI Hub, which publicly hosts models already converted and quantized for the Hexagon NPU, with measured on-device latency published alongside them.

That last detail matters more than people expect. When you are budgeting a perception loop, you are not guessing at throughput, you are reading a number measured on the same class of silicon you are deploying to, so you can pick a model and know what it will cost you in milliseconds.

Just as important, the preparation methodology is public too, not just the finished artifact. The AI Hub Models repo publishes the per-model recipe: how the model was traced and exported, how it was quantized and calibrated, and how it was evaluated on device.

So when you fine-tune one of those models on your own data, you are not starting over on optimization. You take your fine-tuned weights, follow the same documented steps AI Hub used to make the base model fast, and land in the same place with your own version.

When AI Hub does not already host what you need, bring your own. Take a PyTorch, ONNX, or TensorFlow model and run it through AI Hub which will convert and quantize the model, if you’d rather to do locally you can utilize the QAIRT SDK to do the conversion and quantization flow with the same scripts / setup as AI Hub.

That flow lets you generate operating points, which is the most useful lever in the whole process: you trade accuracy against latency deliberately, produce a few variants, and choose the one that fits the robot's real-time budget instead of forcing one size to fit everything.

From there it is almost boring in how smoothly it lands. The optimized model drops straight into qrb_ros_nn_inference, or into a qrb_ros_samples pipeline, as just another artifact in the ROS 2 graph. No bespoke serving layer, no separate runtime to babysit.

The node loads the .bin and runs it on the NPU, and it all stays local: inference happens on-device, which keeps latency tight and keeps your data and your IP on the robot where they belong. For a physical system reacting to the world in real time, local-first is not a nice-to-have, it is the whole point.

Try it today

Everything here has a concrete, public entry point.

Add the PPAs and install: