CodeTheRobot

Ubuntu Linux for Robotics · Lesson 49 of 96

QoS profiles

Inspecting QoS on Ubuntu, matching profiles and the common mismatch warnings.

Estimated time · 45–60 min

Learning goals

What you will understand

  • Explain qos profiles in your own words
  • Use it in a small workstation example
  • Verify the result instead of assuming it worked

Understand the idea first

The mental model

Quality of Service controls reliability, durability, history and depth. Two endpoints on the same topic connect only if their QoS is compatible; a reliable subscriber cannot receive from a best-effort publisher. Sensor topics normally use best-effort (SensorDataQoS), maps use transient-local durability.

When data does not arrive, run ros2 topic info /topic --verbose and compare the profiles. ROS 2 also prints 'incompatible QoS' warnings when it detects a mismatch. From the CLI you can choose the profile for echo: ros2 topic echo --qos-reliability best_effort /scan.

Guided lesson

Work through these steps

  1. 1.

    Open a terminal and record the current state before changing anything.

  2. 2.

    Read the qos profiles commands and predict what each one does.

  3. 3.

    Run the commands one at a time and compare each output with your prediction.

  4. 4.

    Write the commands that worked in a setup note you can repeat later.

Worked example

Read it before you run it

ros2 topic info /scan --verbose
# Show reliability, durability and depth of each publisher and subscriber.
ros2 topic echo /scan --qos-reliability best_effort --once
# Echo with a best-effort profile that matches a sensor publisher.
ros2 topic echo /map --qos-durability transient_local --qos-reliability reliable --once
# Echo a latched map topic.
ros2 doctor --report | grep -i qos
# Look for QoS-related warnings in the system report.

What the example is doing

  1. 1.Lines without sudo only inspect or change files you own; sudo authorizes a system-wide change.
  2. 2.Read command output before moving to the next line. Stop if names, versions, disks, or paths differ from the lesson.
  3. 3.Comments beginning with # explain safety checks and are not executed by the shell.

Watch it run · Messages between nodes

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

/topicpublishersubscribersubscribermessages delivered: 0MESSAGES BETWEEN NODES

Demo for QoS profiles. Expected result: The scan message is printed

Practice code

Now type it yourself

Open a terminal, run the starter line by line (or save it as practice.sh and run bash practice.sh), and replace every TODO with your own command.

# TODO: echo one message from /scan using best_effort reliability

Expected output

The scan message is printed
Stuck? Show the full solution (try it yourself first)
ros2 topic echo /scan --qos-reliability best_effort --once

Expected result

How you know it worked

  • Each command completes without an unexplained error.
  • Your notes contain the command, the important output, and what it proves.

Practical exercise

Apply the lesson

Publish with best-effort QoS and subscribe with reliable QoS, read the incompatibility warning, and fix it. Then echo a /scan topic with the wrong profile and with the right one.

Before you continue

  • You recorded the starting state
  • Every command and output is understood
  • The change can be repeated from your notes

If something goes wrong

A command says permission denied.

Check ownership and permissions first. Do not add sudo unless the command changes a documented system location.

A command or package is not found.

Check spelling, Ubuntu version, enabled repositories, and whether the previous installation command succeeded.