Skip to main content
ROS2-DDSConfig-Optimizer is an LLM-driven auto-tuner for FastDDS configuration. You hand it performance targets (latency, throughput, reliability, CPU, memory) plus a baseline DDS XML, and it iteratively runs your application, benchmarks it, and mutates DDS parameters until the targets are met.
Qualcomm-built, but SoC-agnostic — it runs on any Ubuntu host with ROS 2 Humble or Jazzy, no Qualcomm hardware required. Listed in this section because it’s part of the QRB ROS ecosystem and signals Qualcomm’s investment in broadly-useful ROS 2 tooling, not just silicon plumbing.

​
Why DDS tuning is a problem worth automating

DDS exposes hundreds of knobs — reliability QoS, history depth, heartbeat periods, socket buffers, participant discovery, transport descriptors. Most teams either leave the defaults in place and eat the latency, or hand-tune for weeks per workload. This tool treats DDS configuration as a black-box optimization problem and delegates the parameter search to an LLM driving FastDDS XML.

​
Quick start

Uses uv (≥ 0.7.8) for Python env management.
1

Clone and sync

git clone https://github.com/qualcomm-qrb-ros/ROS2-DDSConfig-Optimizer.git
cd ROS2-DDSConfig-Optimizer
uv sync
2

Provide targets and a baseline config

Fill in user_requirements_template.xml with your latency / throughput / reliability / resource targets, and fastdds_config_template.xml with your baseline DDS config.
3

Run the optimizer

uv run fastdds-optimizer run \
  --requirements /path/to/user_requirements.xml \
  --initial-config /path/to/initial_DDS_config.xml
The best config is written into data/optimization_history/.
4

Inspect the dashboard

uv run fastdds-optimizer dashboard --port 5000
Open http://localhost:5000/ to browse iteration history and compare configs.

​
Requirements

ItemRequirement
OSUbuntu
ROS 2Humble or Jazzy
DDSFastDDS
Python envuv ≥ 0.7.8
Benchmark harnessros2_benchmark

​
Why this helps

AlternativeShort take
Manual FastDDS XML editingFull control, but requires reading hundreds of pages of spec; no automated search; weeks of tuning per workload.
ROS 2 built-in QoS profiles (sensor_data, etc.)Sensible presets but only ~7 of them; covers a small subset of DDS knobs.
iceoryx / rmw_iceoryxDifferent problem (shared-memory transport backend); doesn’t tune QoS.
Hand-rolled benchmark loops + parameter sweepsWorks, but doesn’t transfer between workloads — every project pays the engineering cost again.
The only tool in the ROS 2 ecosystem that treats DDS configuration as a black-box optimization problem with an LLM driving the search. Hand it perf targets and a baseline XML, get back a tuned config without reading the FastDDS spec.