QoS and timing

Every ROS 2 publisher and subscriber carries a quality of service (QoS) profile: rules for how messages are delivered. When a subscriber’s rules ask for something the publisher does not offer, ROS connects nothing and the subscriber receives no messages, with no error by default. This page lists the profiles the workspace’s own nodes use, and the timing the driving code depends on.

The three settings that matter here

create_publisher(Type, topic, 10) in Python means reliable, volatile, keep the last 10. Most of the workspace uses exactly that.

Which combinations connect

The publisher must offer at least what the subscriber requests:

The two “No” rows are the ones that cause silent failures: the topic appears in ros2 topic list, the publisher is running, and the callback never fires.

Profiles in the workspace

These are read from each node’s create_publisher and create_subscription calls. “Default” means reliable, volatile, depth 10.

The topics marked transient local are the ones that change rarely and must reach a node that starts late: a map published once, the racing line, which localizer is in charge, the IMU’s health. Each subscriber to them asks for transient local too, so it receives the stored message at once instead of waiting for the next one, which may never come.

/scan (from urg_node), /joy (from joy_node) and /map (from slam_toolbox) come from packages installed with apt, not from the workspace, so their profiles are not listed here. Read them on the car, as below.

Check a topic’s profile

ros2 topic info /scan --verbose

This lists every publisher and subscriber of the topic with its full profile: Reliability, Durability, History (Depth). A subscriber whose callback never fires, on a topic whose publisher is running, is usually one of the two incompatible rows above.

In a new node

Subscribe with the publisher’s own profile. For sensor and command topics, create_subscription(Type, topic, callback, 10) matches the workspace’s publishers. For a latched topic, copy the publisher’s QoSProfile, as pure_pursuit_node does for /map:

map_qos = QoSProfile(depth=1,
                     reliability=QoSReliabilityPolicy.RELIABLE,
                     durability=QoSDurabilityPolicy.TRANSIENT_LOCAL)
self.map_sub = self.create_subscription(
    OccupancyGrid, self.map_topic, self.map_callback, map_qos)

Rates

At 40 Hz, each control tick has 25 ms. A node that takes longer than that falls behind its own input.

Timeouts

Every safety check in the driving code is a timeout on the age of some input. A message counts as stale once it is this old:

The mux’s 0.2 s is why teleop_launch.py blocks autonomy completely: joy_teleop repeats at 20 Hz, a message every 50 ms, so /teleop never goes 0.2 s without a message and its priority of 100 always wins over /drive’s 10. When both inputs go quiet, the mux publishes nothing, not a zero, so the motor keeps its last command until the VESC’s own command timeout stops it.

Delays

A command reaches the wheels some time after the scan it was computed from. The workspace’s controllers each model part of that delay, from measurements on the car or in the calibrated simulator:

See Follow the gap for how the steering delay limits the gain, and Stanley for how the steering laws predict ahead to cancel it.

Measure it on the car

ros2 topic hz /scan
ros2 topic delay /scan

ros2 topic hz gives the rate and its jitter. ros2 topic delay compares each message’s header timestamp with the time it arrived, which shows how old messages are by the time a subscriber sees them.

Limitations

• The profiles of urg_node, joy_node and slam_toolbox are not listed, because their code is not in the workspace.
• The VESC’s own command timeout is set in VESC Tool, not in the workspace, and is not recorded here.