CodeTheRobot
Course outline

ROS 2 Lyrical Luth · Lesson 14 of 86

QoS (Quality of Service) profiles

Reliability, durability, history and depth, and matching publishers to subscribers.

Estimated time · 60–90 min

Learning goals

What you will understand

  • Explain qos (quality of service) profiles in your own words
  • Use it in a small robotics example
  • Verify the result instead of assuming it worked

Understand the idea first

The mental model

QoS settings describe how messages are delivered. Reliability: reliable (retry lost messages) or best effort (drop them). Durability: volatile (only new subscribers get new data) or transient local (late joiners also get the last message). History and depth: keep the last N messages.

A publisher and subscriber connect only if their QoS is compatible; for example a reliable subscriber cannot receive from a best-effort publisher. Sensors usually use best-effort (rclcpp::SensorDataQoS()), maps use transient local, and commands use reliable. Check with ros2 topic info -v.

Guided lesson

Work through these steps

  1. 1.

    Source the ROS 2 Lyrical environment in a fresh terminal.

  2. 2.

    Read the qos (quality of service) profiles example and identify what each line does.

  3. 3.

    Build only the affected package, source the workspace overlay, and run the example.

  4. 4.

    Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

auto sensor_qos = rclcpp::SensorDataQoS();
// Profile for sensors: best effort, small queue, favours fresh data.
auto map_qos = rclcpp::QoS(1).reliable().transient_local();
// Profile for maps: keep the last message for late subscribers.
auto cmd_qos = rclcpp::QoS(10).reliable();
// Profile for commands: do not lose any.
scan_sub_ = create_subscription<sensor_msgs::msg::LaserScan>("scan", sensor_qos, cb);
// Subscribe with the sensor profile.
map_pub_ = create_publisher<nav_msgs::msg::OccupancyGrid>("map", map_qos);
// Publish the map with the durable profile.
// ros2 topic info /scan --verbose
// Compare the QoS of both ends when nothing arrives.

What the example is doing

  1. 1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
  2. 2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
  3. 3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

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.

requestresponseclientservercalls answered: 0MESSAGES BETWEEN NODES

Demo for QoS (Quality of Service) profiles. Expected result: The late-joining subscriber still receives the last message

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

// publisher side
rclcpp::QoS qos(1);
// TODO: make the QoS reliable and transient_local so late subscribers receive the last message
pub_ = create_publisher<std_msgs::msg::String>("latched", qos);

Expected output

The late-joining subscriber still receives the last message
Stuck? Show the full solution (try it yourself first)
// publisher side
rclcpp::QoS qos(1);
qos.reliable().transient_local();
pub_ = create_publisher<std_msgs::msg::String>("latched", qos);

Expected result

How you know it worked

  • ROS_DISTRO is lyrical in every terminal used for the exercise.
  • The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Publish a topic with best-effort QoS and subscribe with reliable QoS, observe that no data arrives, read the incompatibility warning, then fix it. Publish a latched (transient local) message and start a subscriber late.

Before you continue

  • ROS_DISTRO reports lyrical in every terminal you used
  • The example builds and runs without errors
  • You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.