Verifying New Robot Claims with a Reproducible QoS and URDF Test Log

When a vendor presents a new robot and claims that its software stack reliably coordinates perception, actuation and remote supervision, the claim remains unverified until someone records how the behavior was produced. A practical operating method for new-robot claim verification is to build a reproducible step-by-step record with inputs, observations, exceptions and an owner. Rather than accepting a demonstration as proof, the engineer defines the configuration, runs the stack, notes what the tools actually show, captures mismatches, and assigns responsibility for the next action. Two official ROS 2 Jazzy sources give us the vocabulary and the concrete artifacts needed for such a log: the QoS settings documentation and the URDF visual model tutorial. They let us specify communication policies and describe the robot’s visible geometry in a way another tester can repeat.

Step 1: Record the Inputs Before Launch

The first block of the log records every input that could change the result. For a ROS 2 based new robot, that means the launch invocation, the URDF model path, and the QoS profile choices applied to publishers and subscriptions. The URDF tutorial source shows the exact command used to display a model: ros2 launch urdf_tutorial display.launch.py model:=urdf/01-myfirst.urdf. The log should copy that form with the actual model file and note that the launch loads the model as a parameter for the robot state publisher node, starts joint state and transform publishing nodes, and opens RViz with a configuration file. On the communication side, the QoS settings source explains that publishers and subscriptions by default use keep-last history with queue size 10, reliable reliability, volatile durability and system-default liveliness; the owner must write down whether defaults were kept or whether a sensor-data profile with best-effort reliability and smaller queue was chosen instead. Without this input block, later observations cannot be attributed to a specific setup.

Step 2: Define the Observation Window and Tools

Observations are not vague impressions; they are the state of RViz, the transforms published, and whether QoS-compatible delivery occurs. From the URDF source we know that RViz displays the fixed frame at the transform frame where the grid center is located, and for a single cylinder the visual origin sits at the geometry center so half the shape appears below the grid. The log should state which fixed frame is active and whether each link appears where intended. For multiple shapes joined by a fixed joint, the child link position depends on the parent link position because URDF is a tree with one root; if two shapes overlap, the observation is that both share the same origin until a joint origin offset is added. On the network side, the observation includes whether messages were delivered. The QoS source warns that different profiles on publisher and subscription can be incompatible and prevent delivery, so the owner records whether best-effort or reliable settings were paired correctly across the nodes under test.

Step 3: Execute and Log Normal Behavior

With inputs fixed, the tester executes the launch and writes a plain-language description of the rendered model. Using the tutorial’s own progression as the method, one begins with one shape: a robot named in the XML with a single link whose visual component is a cylinder 0.6 meters long and 0.2 meters radius. Then multiple links are added with joints, and origins are offset by xyz and rpy values so the leg attaches to the torso side rather than overlapping. The log entries should say that the joint origin is defined in the parent’s reference frame and that a missing rpy means the child frame keeps the parent orientation. Normal behavior also covers service and parameter traffic: because parameters are based on services and use a larger queue depth so requests are not lost when the client cannot reach the server, the owner notes whether parameter interactions succeeded during the window.

Step 4: Capture Exceptions and Incompatibilities

An exception in this method is any deviation from the expected render or delivery. Suppose a late-joining subscription receives no data because the publisher was volatile rather than transient local; the exception records that the durability policy did not persist samples for late joiners, which the QoS source describes as the publisher’s responsibility under transient local. Another exception occurs if a deadline duration was set and subsequent messages exceeded the expected maximum time between publications, causing the system to flag missed deadlines. If two nodes used different reliability policies and messages were not exchanged, that is a profile-incompatibility exception and must be logged with the specific policies on each side. The log also notes stale-message exceptions where lifespan duration caused messages to be silently dropped because too much time passed between publishing and reception. Each exception gets a timestamp, the affected node or link, and the observed symptom.

Step 5: Assign the Owner and Next Action

A record without an owner is not operational. For every exception, the log names the person responsible for triage: perhaps the integration engineer who selected the QoS profile, or the model author who wrote the joint origins. If the visual model shows the leg overlapping the base because no joint origin was specified, the owner is the URDF maintainer and the next action is to add xyz and rpy offsets as the tutorial demonstrates. If delivery failed due to mismatched profiles, the owner is the middleware configuration lead and the action is to align history, depth and reliability on both ends. The log should also name who re-runs the reproducible command after the fix, so the cycle of input, observation and exception can be repeated under the same conditions. This owner field turns a passive note into a tracked verification task.

Step 6: Store the Log as Reusable Evidence

The finished record—commands, profile choices, RViz observations, exceptions and owners—becomes the evidence that a new-robot claim was tested rather than merely shown. Because the method uses only the URDF display command and the documented QoS vocabulary, another site can reproduce it with a different model file and the same launch structure. The claim “the robot’s software coordinates its parts reliably” can then be tied to a concrete instance where transforms were published, RViz displayed the intended tree, and delivery policies were compatible. If the claim involved physical behavior beyond the visual model, the same log format extends to later tutorials on articulation and collision properties, but the core evidence starts here. For readers comparing robot families, the internal pages on mobile manipulation platforms, autonomous inspection units and surgical and medical robots show how different categories raise different verification questions; the method above applies to whichever category is under test. A hypothetical example of a failed verification: a tester launches with best-effort sensor profile on one node and reliable on another, sees no joint states arrive, logs the incompatibility, and assigns the network owner to align the profiles—this hypothetical example illustrates why the exception block must precede any conclusion about performance.