Lecture#

Prerequisites#

One-time workspace and environment setup required before running any code in this lecture.

What Is ROS?#

An open-source middleware framework for building, deploying, and connecting robotic software components.

ROS 1 Limitations and ROS 2 Improvements

Table 15 ROS 1 vs. ROS 2#
ROS 1 Limitations	ROS 2 Improvements
Limited support for real-time computing	Improved real-time capabilities
Weak networked communication robustness	Better network management via DDS middleware
Insufficient security features	Enhanced security: encryption and authentication
Scalability issues as node count grows	Cross-platform support (Linux, macOS, Windows)
(none)	Quality of Service (QoS) per topic

ROS 2 Architecture#

ROS 2 runs many specialized, independent processes, each doing exactly one thing.

Publish/Subscribe Model#

Nodes communicate without knowing each other exist; only the topic name and message type must match.

Running Nodes

Two ways to start nodes

ros2 run starts a single node from the command line.
ros2 launch starts multiple nodes from a single command.

ros2 run

ros2 run <package> <executable> finds the executable registered in <package> and launches it as a new OS process in the current terminal.

# Terminal 1
ros2 run demo_nodes_py talker

# Terminal 2
ros2 run demo_nodes_cpp listener

ros2 run starts exactly one node per invocation and blocks the terminal until you press Ctrl-C. You need one terminal per node.

Terminal 1 – talker output:

[INFO] [1741200001.123456789] [talker]: Publishing: 'Hello World: 1'
[INFO] [1741200002.123456789] [talker]: Publishing: 'Hello World: 2'
[INFO] [1741200003.123456789] [talker]: Publishing: 'Hello World: 3'

Each log line contains: severity level ([INFO]), timestamp in seconds since epoch, node name ([talker]), and the user-defined message. The talker publishes one std_msgs/msg/String message per second on the topic /chatter by default.

Terminal 2 – listener output:

[INFO] [1741200001.145678901] [listener]: I heard: [Hello World: 1]
[INFO] [1741200002.145678901] [listener]: I heard: [Hello World: 2]
[INFO] [1741200003.145678901] [listener]: I heard: [Hello World: 3]

The timestamp is slightly later than the talker’s – this is the network and middleware delivery latency. Always check that the counter in the listener matches the talker. A gap indicates dropped messages, a QoS mismatch, or a network issue.

ros2 launch

ros2 launch <package> <launch_file> starts an entire set of nodes defined in a launch file as a single command, replacing the need for multiple terminals.

ros2 launch demo_nodes_py talker_listener.launch.py

All node output appears in the same terminal, prefixed by node name. A single Ctrl-C stops the entire system.

Expected output:

[INFO] [talker-1]: Publishing: 'Hello World: 1'
[INFO] [listener-1]: I heard: [Hello World: 1]
[INFO] [talker-1]: Publishing: 'Hello World: 2'
[INFO] [listener-1]: I heard: [Hello World: 2]

The -1 suffix is appended by the launch system to give each process a unique identifier in the log output.

Table 16 ros2 run vs. ros2 launch#
Criterion	ros2 run	ros2 launch
Nodes started	One	Many
Terminals needed	One per node	One for everything
Output	Single node only	All nodes, prefixed by name
Typical use	Development, debugging	Integration, demos
Stop all nodes	Ctrl-C in each terminal	Single Ctrl-C

Note

Use ros2 run when you want to focus on a single node. Use ros2 launch when you need the full system running together.

ROS 2 Setup#

Creating and building a workspace and Python package.

Writing Nodes#

A node without spinning exits immediately. A node without callbacks has nothing to respond to.

Interfaces

A ROS 2 interface is a typed data contract shared between nodes. Interfaces are defined in .msg, .srv, and .action files and compiled into language-specific code at build time.

Three kinds of interfaces

Messages (.msg): one-way data sent over a topic.
Services (.srv): request/response pairs – one node calls, another replies.
Actions (.action): long-running tasks with goal, feedback, and result.

Publishers and subscribers use messages. Services and actions are covered in a later lecture.

Standard Message Packages

Standard message packages ship precompiled with ROS 2. After sourcing ROS 2 you can import them directly:

std_msgs: primitive types – Bool, String, Int8/16/32/64, UInt8/16/32/64, Float32, Float64, Header.
geometry_msgs: spatial data – Point, Pose, Twist, Transform, Vector3.
sensor_msgs: sensor data – Image, LaserScan, PointCloud2, Imu, NavSatFix.
nav_msgs: navigation – Odometry, Path, OccupancyGrid.

Note

These packages are installed under /opt/ros/jazzy/ via sudo apt install ros-jazzy-std-msgs etc. You never build them yourself unless you define custom message types.

From Text Files to Language Code

Each message is defined in a plain-text .msg file that declares field names and types – one per line.

# geometry_msgs/msg/Point.msg
float64 x
float64 y
float64 z

The precompiled Python import:

from geometry_msgs.msg import Point

The .msg definition is language-agnostic – the same file generates Python, C++, and other bindings. ros2 interface show geometry_msgs/msg/Point prints the original .msg source.

Primitive Types vs. std_msgs

In a .msg file, float64, int32, bool, and so on are IDL primitive types – the raw building blocks of the interface definition language, not ROS message types.

float64 x in a .msg file means the field x holds a plain 64-bit floating point number – it maps to float in Python and double in C++.
std_msgs/Float64 is a wrapper message: a full ROS 2 message whose only field is float64 data. It exists so you can publish a single number on a topic.
Use primitive types (float64, int32, etc.) inside your own .msg field definitions.
Use std_msgs wrappers only when publishing a bare scalar on a topic and no richer message type exists.

Introspecting Interfaces

ros2 interface list -m                         # all message types
ros2 interface show geometry_msgs/msg/Pose     # fields of a message
ros2 interface package geometry_msgs           # all interfaces in a package

Creating and Populating a Message Object

from geometry_msgs.msg import Pose, Point, Quaternion

def main(args=None):
    pose = Pose()

    pose.position = Point()
    pose.position.x = 1.0
    pose.position.y = 2.5
    pose.position.z = 0.0

    pose.orientation = Quaternion()
    pose.orientation.x = 0.0
    pose.orientation.y = 0.0
    pose.orientation.z = 0.0
    pose.orientation.w = 1.0  # identity rotation

    print(pose)

Pose is a composite message: it contains two nested message fields. Nested types must be imported and instantiated separately. orientation.w = 1.0 is the identity quaternion (no rotation).

Spinning

Spinning keeps a node alive and responsive. rclpy.spin(node) blocks until the node is shut down.

Without spinning, the node exits immediately and no callbacks ever run.

Threads

Definition: Thread

A thread is the smallest unit of execution inside a process. A process can have multiple threads running concurrently, sharing the same memory.

Browser process with multiple threads — Fig. 47 Example: A browser process with multiple threads.#

The Main Thread

Every Python program starts with one thread (the main thread). When you call rclpy.spin(node), that main thread is handed over to the ROS 2 executor, which runs it in a loop checking for work to do.

rclpy.spin() blocks the main thread – no code after it runs until the node is shut down (e.g., Ctrl-C).
The ROS executor uses this thread to fire callbacks, service handlers, and timer functions one at a time.

Fig. 49 Main thread blocked by spin loop, executor dispatching callbacks.#

Why Must You Spin?

Spinning activates the ROS 2 executor. Without it, the node is registered but completely passive – nothing ever runs.

Incoming messages: subscriber callbacks are only invoked while spinning.
Timer callbacks: create_timer() registers a timer, but the timer only fires while the executor is running.
Service requests: a service server only processes requests while spinning.
Action servers and clients: goal handling, feedback, and result delivery all require an active executor.
Parameter updates: parameter change callbacks are also dispatched by the executor.

rclpy.spin(node) is the event loop of a ROS 2 node. Without it, the node is a program that starts, does nothing, and exits.

Update scripts/run_advanced_node.py to spin

import rclpy
from first_pkg.advanced_node import AdvancedNode

def main(args=None):
    rclpy.init(args=args)
    node = AdvancedNode("advanced_node")
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        node.get_logger().info("Shutting down.")
    finally:
        node.destroy_node()
        rclpy.shutdown()

if __name__ == "__main__":
    main()

rclpy.spin(node): blocks the main thread, processing callbacks as they arrive.
except KeyboardInterrupt: catches Ctrl-C from the terminal and logs a clean shutdown message. Without this, the traceback would be printed to the terminal.
finally: runs regardless of how the try block exits. This guarantees cleanup always happens.
node.destroy_node(): releases all ROS 2 resources held by the node (publishers, subscribers, timers).
rclpy.shutdown(): shuts down the ROS 2 runtime. Always the last call.

Spinning Alternatives

# Blocks forever -- standard choice for most nodes
rclpy.spin(node)

# Processes one batch of callbacks then returns
rclpy.spin_once(node)

# Blocks until a Future completes -- used for async service calls
rclpy.spin_until_future_complete(node, future)

# Manual spin loop using spin_once
while rclpy.ok():
    rclpy.spin_once(node, timeout_sec=0.1)
    # do other work here

Note

Use rclpy.spin(node) for all standard nodes. Only use spin_once() if you have a specific reason to interleave ROS 2 processing with non-ROS work. The spin loop always lives in the entry point script, not in the node class – this keeps the class reusable by any executor or script without modification.

Publishers

A publisher sends messages regardless of whether anyone is listening. The topic name and message type are the only contract.

File: first_pkg/publisher_demo.py

Workflow

Create a publisher object: specify message type, topic name, and QoS queue depth.
Create a message instance and populate its fields.
Publish inside a timer callback at a fixed rate.

Create a Publisher Object

from std_msgs.msg import Int64
from rclpy.node import Node

class PublisherDemo(Node):
    def __init__(self, node_name: str):
        super().__init__(node_name)
        self._publisher = self.create_publisher(
            Int64,      # message type
            "counter",  # topic name
            10          # QoS queue depth
        )

create_publisher() takes three arguments: message type, topic name, and queue depth – all three are required.
The topic name string: by convention use snake_case; a leading "/" is added automatically by ROS 2.
Queue depth 10: up to 10 undelivered messages are buffered; older ones are dropped when the queue is full.
Store the result in self._publisher so it is not garbage collected when __init__ returns.

Create a Message Instance

from std_msgs.msg import Int64

# Option A: create once in __init__, reuse in every callback (preferred)
self._message = Int64()

# Option B: create a new instance on every publish
def _timer_callback(self):
    msg = Int64()
    msg.data = self._counter
    self._publisher.publish(msg)

# Option A usage in callback:
def _timer_callback(self):
    self._message.data = self._counter
    self._publisher.publish(self._message)

Option A (preferred): create the object once in __init__ and reuse it – avoids repeated memory allocation on every timer tick.

Publish Inside a Timer Callback

class PublisherDemo(Node):
    def __init__(self, node_name: str):
        super().__init__(node_name)
        self._counter = 0
        self._message = Int64()
        self._publisher = self.create_publisher(Int64, "counter", 10)
        self._timer = self.create_timer(2.0, self._timer_callback)

    def _timer_callback(self):
        self._message.data = self._counter
        self._publisher.publish(self._message)
        self.get_logger().info(f"Publishing: {self._counter}")
        self._counter += 1

The callback runs in the executor thread – never block it with time.sleep() or heavy computation. Always publish inside a callback rather than a while loop.

Run and Inspect

# Terminal 1
colcon build --symlink-install --packages-select first_pkg
source install/setup.bash
ros2 run first_pkg publisher_demo

# Terminal 2
ros2 node list
ros2 node info /publisher_demo
ros2 topic list -t
ros2 topic echo /counter
ros2 topic hz /counter
rqt_graph

Quality of Service (QoS)

QoS is the set of policies that govern how messages are delivered between publishers and subscribers. It is the contract between the two parties on reliability, history, and durability.

Warning

Publisher and subscriber QoS policies must be compatible or DDS silently refuses the connection – no error, no data.

The Four Core QoS Policies

Reliability: RELIABLE retransmits dropped messages and guarantees delivery. BEST_EFFORT skips retransmission for lower latency. Use RELIABLE for commands and critical data; BEST_EFFORT for high-frequency sensor streams.
Durability: TRANSIENT_LOCAL caches the last message so late-joining subscribers receive it immediately. VOLATILE sends nothing to late joiners. Use TRANSIENT_LOCAL for topics published once but needed by nodes that start later (e.g. robot description, map).
History: KEEP_LAST buffers the last N messages (depth). KEEP_ALL retains every message at the cost of unbounded memory.
Deadline: maximum allowed gap between consecutive messages. If no message arrives within the interval, the middleware triggers a callback – useful for detecting sensor failures.

Default vs. Explicit QoS in Python

from rclpy.qos import QoSProfile, ReliabilityPolicy, DurabilityPolicy, HistoryPolicy

# Passing an integer sets queue depth with all-default policies
self._publisher = self.create_publisher(Int64, "counter", 10)

# Equivalent explicit profile
qos = QoSProfile(
    depth=10,
    reliability=ReliabilityPolicy.RELIABLE,
    durability=DurabilityPolicy.VOLATILE,
    history=HistoryPolicy.KEEP_LAST,
)
self._publisher = self.create_publisher(Int64, "counter", qos)

Predefined QoS Profiles

from rclpy.qos import qos_profile_sensor_data
from rclpy.qos import qos_profile_system_default

# Sensor data: BEST_EFFORT, VOLATILE, depth 5
self._publisher = self.create_publisher(LaserScan, "scan", qos_profile_sensor_data)

# System default: RELIABLE, VOLATILE, depth 10
self._publisher = self.create_publisher(Int64, "counter", qos_profile_system_default)

qos_profile_sensor_data: best effort, volatile, depth 5. Designed for high-frequency sensor streams where losing an occasional message is acceptable.
qos_profile_system_default: reliable, volatile, depth 10. The implicit default when you pass an integer.
qos_profile_services_default: reliable, volatile. Used internally by services and actions.

Note

Prefer predefined profiles over manual QoSProfile construction when your use case matches one of them.

QoS Compatibility Rules

A publisher and subscriber only connect if their policies are compatible. Incompatible QoS causes a silent failure – no error, no warning, no data.

Reliability: a RELIABLE subscriber will not connect to a BEST_EFFORT publisher. The reverse works.
Durability: a TRANSIENT_LOCAL subscriber will not connect to a VOLATILE publisher. The reverse works.
Deadline: subscriber deadline must be greater than or equal to publisher deadline.

Diagnosing QoS Mismatches

ros2 topic info /counter -v
ros2 doctor --report | grep qos

Warning

A subscriber that receives nothing is often a QoS mismatch, not a bug in your code. Always check QoS compatibility before debugging elsewhere.

Subscribers

A subscriber is unaware of which publisher sends the messages. Its sole objective is to receive and process them.

File: first_pkg/subscriber_demo.py

Workflow

Create a subscription object: specify message type, topic name, callback, and QoS queue depth.
Define a callback function to process each incoming message.
Spin the node – the ROS 2 executor delivers messages to the callback as they arrive.

Create a Subscription Object

from std_msgs.msg import Int64
from rclpy.node import Node

class SubscriberDemo(Node):
    def __init__(self, node_name: str):
        super().__init__(node_name)
        self._subscriber = self.create_subscription(
            Int64,                        # message type
            "counter",                    # topic name
            self._subscriber_callback,    # callback
            10                            # QoS queue depth
        )
        self.get_logger().info("Subscriber initialized.")

create_subscription() takes four arguments: message type, topic name, callback, and queue depth – all four are required.
Topic name and message type must match the publisher exactly – a mismatch causes a silent failure with no data received.
The callback is passed by reference as self._subscriber_callback, not called – no parentheses.
Store the result in self._subscriber so it is not garbage collected when __init__ returns.

Define the Callback

from std_msgs.msg import Int64

# Named callback (preferred)
def _subscriber_callback(self, msg: Int64):
    self.get_logger().info(f"Received: {msg.data}")

# Equivalent lambda (for simple single-expression callbacks only)
self._subscriber = self.create_subscription(
    Int64,
    "counter",
    lambda msg: self.get_logger().info(f"Received: {msg.data}"),
    10,
)

The callback receives a single argument: the incoming message object. Type-hint it (msg: Int64) for IDE autocompletion on fields.
Named callback (preferred): easier to read, test, and extend. Use whenever the body is more than one expression.
Lambda: acceptable for trivial one-liners but becomes unreadable quickly.
Keep callbacks fast – a slow callback blocks the executor and causes queue buildup on the subscriber side.

Complete Subscriber Node

import rclpy
from rclpy.node import Node
from std_msgs.msg import Int64

class SubscriberDemo(Node):
    def __init__(self, node_name: str):
        super().__init__(node_name)
        self._subscriber = self.create_subscription(
            Int64, "counter",
            self._subscriber_callback, 10
        )
        self.get_logger().info("Subscriber initialized.")

    def _subscriber_callback(self, msg: Int64):
        self.get_logger().info(f"Received: {msg.data}")

def main(args=None):
    rclpy.init(args=args)
    node = SubscriberDemo("subscriber_demo")
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()

if __name__ == "__main__":
    main()

Note

If the callback is never invoked, check topic name, message type, and QoS compatibility before assuming the code is broken.

Communication Scenarios#

What actually happens to messages when publishers and subscribers run at different speeds?

Setup for all scenarios

Publisher rate: 2 Hz (one message every 0.5 s).
QoS queue depth: 3 on both publisher and subscriber.
Policy: KEEP_LAST – oldest message dropped when queue is full.

Scenario 1 – No Subscriber

Setup: publisher at 2 Hz, no subscriber connected, QoS depth 3.

Table 17 Publisher at 2 Hz, no subscriber connected, QoS depth 3#
Time	Publisher action	Result
t = 0.0 s	Publishes msg1	No matching subscriber – discarded by DDS
t = 0.5 s	Publishes msg2	No matching subscriber – discarded by DDS
t = 1.0 s	Publishes msg3	No matching subscriber – discarded by DDS
t = 1.5 s	Publishes msg4	No matching subscriber – discarded by DDS

DDS does not buffer messages for a subscriber that does not exist. Messages are discarded immediately.
The publisher continues running normally with no performance impact.
Messages are lost forever unless TRANSIENT_LOCAL durability is configured – in which case the last message is cached and delivered to any subscriber that joins later.

Note

This is the expected behavior for VOLATILE durability (the default). If you need late-joining subscribers to receive the last value, switch to TRANSIENT_LOCAL on both publisher and subscriber.

Scenario 2 – Fast Subscriber

Setup: publisher at 2 Hz, callback duration 0.1 s, QoS depth 3 on both sides.

Table 18 Publisher at 2 Hz, callback duration 0.1 s, QoS depth 3#
Time	Publisher	Queue	Callback	Notes
t = 0.0 s	Publishes msg1	[msg1]	Starts on msg1	Queue: 1
t = 0.1 s	–	[]	Completes	Queue: 0, ready
t = 0.5 s	Publishes msg2	[msg2]	Starts on msg2	Queue: 1
t = 0.6 s	–	[]	Completes	Queue: 0, ready
t = 1.0 s	Publishes msg3	[msg3]	Starts on msg3	Queue: 1
t = 1.1 s	–	[]	Completes	Queue: 0, ready

The queue never builds up – it holds at most one message at a time.
Latency between publish and processing is minimal.
The system is healthy – no messages are dropped.
This is the ideal scenario for real-time sensor processing.

Note

Design your callbacks to be faster than the publish rate. If the callback cannot keep up, offload heavy computation to a separate thread.

Scenario 3 – Slow Subscriber

Setup: publisher at 2 Hz, callback duration 1.7 s, QoS depth 3 on both sides.

Table 19 Publisher at 2 Hz, callback duration 1.7 s, QoS depth 3#
Time	Publisher	Queue	Callback	Notes
t = 0.0 s	Publishes msg1	[msg1]	Starts on msg1	Queue: 1
t = 0.5 s	Publishes msg2	[msg2]	Still on msg1	Queue: 1
t = 1.0 s	Publishes msg3	[msg2, msg3]	Still on msg1	Queue: 2
t = 1.5 s	Publishes msg4	[msg2, msg3, msg4]	Still on msg1	Queue full (depth 3)
t = 1.7 s	–	[msg3, msg4]	Starts on msg2	msg2 dequeued
t = 2.0 s	Publishes msg5	[msg3, msg4, msg5]	Still on msg2	Queue full again
t = 2.5 s	Publishes msg6	[msg4, msg5, msg6]	Still on msg2	msg3 dropped
t = 3.4 s	–	[msg4, msg5, msg6]	Starts on msg3	msg3 dequeued
t = 3.5 s	Publishes msg7	[msg5, msg6, msg7]	Still on msg3	msg4 dropped

Once the queue reaches depth 3, every new message evicts the oldest one – KEEP_LAST policy.
The subscriber always processes stale data – it is never caught up with real time.
Increasing queue depth delays the first drop but does not solve the underlying problem.

Summary of Scenarios

Table 20 Comparison of publisher-subscriber timing scenarios at 2 Hz, QoS depth 3#
Scenario	Callback time	Messages lost	Latency
No subscriber	–	All	N/A
Fast subscriber	0.1 s	None	Minimal
Slow subscriber	1.7 s	Yes (oldest)	Grows over time

Diagnostic Commands

ros2 topic hz /counter        # check publish rate
ros2 topic echo /counter      # watch messages in real time
ros2 topic info /counter -v   # check QoS on both sides

Note

If ros2 topic hz shows the expected rate but your node output is slower, your callback is the bottleneck – not the publisher. Offload heavy work to a separate thread or reduce the publish rate.

Lecture#

Prerequisites#

What Is ROS?#

ROS 2 Architecture#

Publish/Subscribe Model#

ROS 2 Setup#

Writing Nodes#

Communication Scenarios#

This Page