A Step-by-Step Log for Tuning ROS 2 QoS and Checking a URDF Model

On 2026-10-28 our robotics source tracking desk ran a reproducible operating method for two everyday ROS 2 Jazzy tasks: tuning Quality of Service settings for a node pair, and building a visual URDF model from scratch. The point was not to publish a finished product claim but to keep a clean, auditable record with inputs, observations, exceptions, and a named owner. This article is that record, written for engineers who maintain internal robot software and need a routine they can repeat next week.

Why a reproducible step-by-step record matters

A daily robotics source tracker sees many announcements and documentation updates. When a team changes middleware behavior or model geometry, the useful artifact is not the change alone but the trace of how it was produced. We set out to show a practical operating method: log every input, note what you actually observe in RViz or on the wire, flag exceptions when the result differs from the documented default, and assign an owner who can re-run the procedure. The two official ROS 2 documentation sources we used are the QoS settings reference for Jazzy and the URDF visual model tutorial. Both were treated as reference evidence for the expected behavior, not as instructions we blindly copied without observation.

Inputs and setup for the first task: QoS profile selection

Our first input set was a ROS 2 Jazzy workspace with one publisher and one subscription on a topic carrying periodic range readings from a simulated proximity sensor. The documented base QoS policies include history (keep last / keep all), depth as queue size for keep-last, reliability (best effort / reliable), durability (transient local / volatile), deadline, lifespan, liveliness, and lease duration, together with system-default or unspecified-duration options. The default publisher and subscription profile is keep-last with queue size 10, reliable, volatile, and system-default liveliness, with deadline, lifespan, and lease durations left as default. For sensor data the documentation describes a profile using best-effort reliability and a smaller queue size because timely readings matter more than completeness. We recorded these as inputs before changing any code, and the owner of this task was the integration engineer on duty.

Observations while applying the sensor-data QoS profile

We switched the subscription to the sensor-data style behavior implied by the documentation: best-effort reliability with a smaller queue size than the default ten. While the publisher still used the default reliable profile, the connection remained compatible for delivery, but when we later set both ends explicitly to mismatched durability we observed the message flow stopping. The exception logged was that a late-joining subscription with volatile durability did not receive the earlier samples, whereas a transient-local publisher would persist them for late joiners. We also noted that lifespan expiration silently drops messages older than the set duration, which we did not enable but recorded as available policy. The observation is concrete: with best effort, bursts under a lossy link lost individual samples, which matched the tutorial source description of sensor profiles sacrificing some readings for lower latency.

Exceptions and how they were handled

The first exception was a configuration mistake: we initially gave the subscription a queue depth larger than intended while still using keep-last history, which honored the depth but consumed more buffer than the small sensor profile needs. It did not break communication, so we recorded it as a minor tuning note rather than a failure. The second exception was a compatibility block when reliability and durability were mixed across endpoints in a way the transport refuses; we reverted both nodes to matched profiles and confirmed delivery resumed. No invented packet-loss numbers or latency statistics appear in this log; we only recorded qualitative observations against the documented policy meanings. For context on related communication topics, our tracker also follows node and middleware reports.

Inputs and steps for the second task: building a visual URDF

The second input was an empty URDF file in the same workspace, with the joint_state_publisher package available and the urdf_tutorial display launch script ready. The documented tutorial builds a model resembling R2D2 starting from one cylinder link named base_link with length 0.6 meters and radius 0.2 meters, then adds a second link as a box of size 0.6 by 0.1 by 0.2 meters joined by a fixed joint, then sets origins to stop the shapes from overlapping. We followed the sequence in the source: one shape first, then multiple shapes with a fixed parent-child joint to form the tree structure with one root link, then origin tags using xyz and rpy offsets so the leg attaches to the side of the torso rather than sharing the same center.

Observations, exceptions, and owner for the URDF check

Launching the display script loaded the model as a parameter for the robot_state_publisher node, started joint state publishing, and opened RViz with a configuration file where the fixed frame was the single link transform. The initial single-cylinder observation was that the visual origin sits at the geometry center, so half of the cylinder appears below the grid—an expected default noted in the source. With two links and only a joint, both shapes overlapped at the same origin; adding a joint origin of xyz 0 -0.22 0.25 moved the child up and to the side, and a visual origin of rpy 0 1.57075 0 with xyz 0 0 -0.3 rotated and offset the leg box. The exception was a malformed XML tag that the parser rejected on first write; the owner, the same integration engineer, corrected the nesting and re-launched. The result was a visible non-overlapping visual model in RViz, recorded without claiming any physical or collision properties, which later tutorials add. Related geometry and model reports are tracked under visual and description resources, and broader mobile-base cases under platform and mobility entries.