Creating a subscriber node in ROS - Mechanics & Internals

Overview - Creating a subscriber node

What is it?

A subscriber node in ROS (Robot Operating System) is a program that listens for messages on a specific topic. It receives data published by other nodes and processes it. This allows different parts of a robot system to communicate asynchronously and react to events or sensor data.

Why it matters

Without subscriber nodes, ROS nodes would not be able to receive information from each other, making it impossible to build modular and reactive robot software. Subscriber nodes enable real-time data flow and coordination, which is essential for tasks like sensor reading, control, and decision-making.

Where it fits

Before learning to create subscriber nodes, you should understand basic ROS concepts like nodes, topics, and messages. After mastering subscribers, you can learn about publishers, services, actions, and more complex communication patterns in ROS.

Mental Model

Core Idea

A subscriber node waits and listens for messages on a topic, then acts on the received data whenever it arrives.

Think of it like...

It's like a radio listener tuned to a specific station; whenever the station broadcasts a song, the listener hears it and can respond, like dancing or singing along.

┌───────────────┐       ┌───────────────┐
│ Publisher Node│──────▶│ Topic (Channel)│──────▶┌───────────────┐
└───────────────┘       └───────────────┘       │ Subscriber Node│
                                                  └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding ROS Topics and Messages

Concept: Learn what topics and messages are in ROS and how they enable communication.

In ROS, nodes communicate by sending messages over named channels called topics. A message is a structured data packet, like sensor readings or commands. Topics are like mailing addresses where messages are sent and received.

Result

You understand that topics carry messages and nodes use them to talk to each other.

Knowing topics and messages is essential because subscribers rely on these to receive data.

2

Foundation

Setting Up a Basic ROS Node

Concept: Learn how to create a simple ROS node that can run and be recognized by the ROS system.

A ROS node is a program that registers with the ROS master. You write code that initializes the node with a unique name and keeps it running to perform tasks.

Result

You can create and run a ROS node that does nothing but exists in the ROS network.

Understanding node setup is critical because subscribers must be nodes to receive messages.

3

Intermediate

Creating a Subscriber Callback Function

🤔Before reading on: do you think the subscriber processes messages immediately or waits for a batch? Commit to your answer.

Concept: Learn how to define a function that runs every time a new message arrives on the subscribed topic.

The subscriber node uses a callback function that ROS calls automatically when a message is received. This function takes the message as input and processes it, like printing data or triggering actions.

Result

Your subscriber node reacts instantly to incoming messages by running the callback.

Understanding callbacks is key because they enable asynchronous, event-driven processing in ROS.

4

Intermediate

Subscribing to a Topic with Correct Message Type

🤔Before reading on: do you think you can subscribe to any topic with any message type? Commit to your answer.

Concept: Learn that the subscriber must specify the exact message type the topic uses to receive data correctly.

When creating a subscriber, you provide the topic name and the message type (e.g., std_msgs/String). ROS uses this to deserialize messages properly. Mismatched types cause errors or crashes.

Result

Your subscriber node receives and understands messages without errors.

Knowing message types prevents runtime errors and ensures data integrity.

5

Intermediate

Keeping the Subscriber Node Alive

Concept: Learn how to keep the subscriber node running so it can continuously listen for messages.

ROS nodes must keep spinning to process callbacks. Using functions like ros::spin() in C++ or rospy.spin() in Python keeps the node alive and responsive.

Result

Your subscriber node stays active and processes messages as they come.

Understanding the event loop is crucial to maintain continuous message handling.

6

Advanced

Handling Message Queue and Latency

🤔Before reading on: do you think subscriber nodes always process messages instantly with zero delay? Commit to your answer.

Concept: Learn about message queues and how subscriber nodes handle bursts of messages or slow processing.

Subscribers have a queue size that buffers incoming messages. If messages arrive faster than processed, older messages may be dropped. Proper queue size and processing speed prevent data loss or lag.

Result

Your subscriber node manages message flow smoothly without missing important data.

Knowing queue management helps build reliable, real-time ROS applications.

7

Expert

Using Subscriber Node with Multi-threading

🤔Before reading on: do you think subscriber callbacks block each other or run in parallel by default? Commit to your answer.

Concept: Learn how to use multi-threaded spinning to allow subscriber callbacks to run concurrently for better performance.

ROS supports multi-threaded spinning where callbacks run in separate threads. This avoids blocking when one callback takes long, improving responsiveness in complex systems.

Result

Your subscriber node handles multiple messages simultaneously without delays.

Understanding multi-threading in subscribers unlocks scalable and efficient ROS node design.

Under the Hood

When a subscriber node starts, it registers with the ROS master to listen on a topic. The ROS middleware manages network connections and delivers serialized messages to the subscriber. Upon receiving a message, ROS deserializes it and calls the subscriber's callback function in the node's process. The node's event loop keeps running to handle incoming messages continuously.

Why designed this way?

ROS was designed for distributed robotic systems needing flexible, asynchronous communication. Using topics with publishers and subscribers decouples components, allowing independent development and scaling. The callback and event loop model fits event-driven programming, which is efficient for sensor-driven robotics.

┌───────────────┐
│ ROS Master    │
├───────────────┤
│ Topic Registry│
└──────┬────────┘
       │
       │ Registers subscriber
       ▼
┌───────────────┐
│ Subscriber    │
│ Node          │
│ ┌───────────┐ │
│ │ Callback  │ │
│ │ Function  │ │
│ └───────────┘ │
└──────┬────────┘
       │ Receives messages
       ▼
┌───────────────┐
│ Network Layer │
│ (Serialization│
│  & Transport) │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do subscriber nodes receive messages even if no callback is defined? Commit yes or no.

Common Belief: Subscriber nodes automatically receive and process messages without needing a callback function.

Reality: Subscriber nodes must define a callback function to process incoming messages; otherwise, messages are received but ignored.

Why it matters: Without a callback, the node wastes resources receiving messages it never uses, leading to confusion and bugs.

Quick: Can a subscriber node receive messages from any topic regardless of message type? Commit yes or no.

Common Belief: Subscribers can listen to any topic regardless of the message type specified.

Reality: Subscribers must match the exact message type of the topic; mismatched types cause errors or no data reception.

Why it matters: Incorrect message types cause runtime failures and prevent communication, blocking system functionality.

Quick: Do subscriber callbacks run in parallel by default? Commit yes or no.

Common Belief: Subscriber callbacks run in parallel automatically, so no blocking occurs.

Reality: By default, callbacks run sequentially in a single thread unless multi-threaded spinning is explicitly used.

Why it matters: Assuming parallelism can cause performance bottlenecks and unresponsive nodes in complex systems.

Quick: Does increasing the subscriber queue size always improve message handling? Commit yes or no.

Common Belief: A larger queue size always ensures no messages are lost and improves performance.

Reality: Too large a queue can increase memory use and latency; it does not guarantee better real-time performance.

Why it matters: Misconfiguring queue size can cause delays or resource exhaustion, harming system stability.

Expert Zone

1

Subscriber nodes can use message filters to subscribe conditionally, reducing unnecessary processing.

2

ROS2 introduces QoS (Quality of Service) settings for subscribers, allowing fine control over reliability and latency.

3

Callback groups in ROS2 enable grouping callbacks for better concurrency control and thread safety.

When NOT to use

Subscriber nodes are not suitable when synchronous request-response communication is needed; use ROS services or actions instead. For guaranteed delivery and complex workflows, consider action servers or service clients.

Production Patterns

In real systems, subscriber nodes often include message throttling, filtering, and multi-threaded spinning to handle high-frequency data. They also integrate with lifecycle management to start and stop subscriptions dynamically.

Connections

Event-driven programming

Subscriber callbacks are an example of event-driven design where code reacts to incoming events asynchronously.

Understanding event-driven programming helps grasp how subscriber nodes efficiently handle data without blocking.

Publish-subscribe messaging pattern

ROS subscriber nodes implement the publish-subscribe pattern common in distributed systems.

Knowing this pattern clarifies how decoupled communication works and why it scales well in robotics.

Radio communication

Subscriber nodes are like radio receivers tuned to a frequency (topic) to get broadcasts (messages).

This cross-domain link shows how tuning and listening concepts apply in both wireless and software messaging.

Common Pitfalls

#1 Subscriber node exits immediately after starting, missing messages.

Wrong approach:

int main(int argc, char **argv) {
ros::init(argc, argv, "subscriber_node");
ros::NodeHandle nh;
ros::Subscriber sub = nh.subscribe("chatter", 1000, chatterCallback);
return 0;
}

Correct approach:

int main(int argc, char **argv) {
ros::init(argc, argv, "subscriber_node");
ros::NodeHandle nh;
ros::Subscriber sub = nh.subscribe("chatter", 1000, chatterCallback);
ros::spin();
return 0;
}

Root cause:

The node exits because ros::spin() is missing, so the program does not wait for messages.

#2 Subscribing with wrong message type causing runtime errors.

Wrong approach:

ros::Subscriber sub = nh.subscribe("chatter", 1000, std_msgs::Int32, chatterCallback);

Correct approach:

ros::Subscriber sub = nh.subscribe("chatter", 1000, chatterCallback);

Root cause:

Mismatch between the topic's actual message type and the subscriber's expected type causes deserialization failure.

#3 Callback function takes no parameters, so message data is inaccessible.

Wrong approach:

void chatterCallback() {
ROS_INFO("Message received");
}

Correct approach:

void chatterCallback(const std_msgs::String::ConstPtr& msg) {
ROS_INFO("I heard: %s", msg->data.c_str());
}

Root cause:

Callback must accept the message parameter to access the data sent by the publisher.

Key Takeaways

Subscriber nodes listen to topics and react to messages using callback functions.

Matching the correct message type and keeping the node alive with ros::spin() are essential for proper operation.

Callbacks run sequentially by default; multi-threading requires explicit setup for concurrency.

Managing message queues and processing speed prevents data loss and latency issues.

Subscriber nodes enable modular, asynchronous communication critical for building flexible robot systems.

Practice

1.

What is the main purpose of a subscriber node in ROS?

easy

A. To send messages to other nodes

B. To listen and react to messages published on a topic

C. To create new topics for communication

D. To store messages permanently

Solution

1. Step 1: Understand the role of a subscriber node

   A subscriber node listens to messages sent on a specific topic in ROS.

2. Step 2: Compare options with the subscriber role

   Only To listen and react to messages published on a topic describes listening and reacting to messages, which matches the subscriber's purpose.

3. Final Answer:

   To listen and react to messages published on a topic -> Option B

4. Quick Check:

   Subscriber node = listens to messages [OK]

Hint: Subscriber nodes always listen to topics, not send [OK]

Common Mistakes:

• Confusing subscriber with publisher
• Thinking subscriber creates topics
• Assuming subscriber stores messages permanently

2.

Which of the following is the correct way to create a subscriber in ROS 2 Python?

node.create_subscription(____, 'chatter', callback, 10)

easy

A. std_msgs.msg.String

B. String

C. std_msgs/String

D. string

Solution

1. Step 1: Identify the correct message type import

   In ROS 2 Python, message types are imported as modules, e.g., std_msgs.msg.String.

2. Step 2: Match the correct syntax for create_subscription

   The first argument must be the full message type class, so std_msgs.msg.String is correct.

3. Final Answer:

   std_msgs.msg.String -> Option A

4. Quick Check:

   Message type = std_msgs.msg.String [OK]

Hint: Use full message type path with .msg in ROS 2 Python [OK]

Common Mistakes:

• Using just 'String' without module path
• Using slash notation like 'std_msgs/String'
• Using lowercase 'string' instead of class name

3.

Given this ROS 2 Python subscriber code snippet, what will be printed when a message with data 'Hello' arrives?

def callback(msg):
    print(f'Received: {msg.data}')

node.create_subscription(std_msgs.msg.String, 'chatter', callback, 10)

medium

A. Received: msg.data

B. Hello

C. Received: Hello

D. msg.data

Solution

1. Step 1: Understand the callback function

   The callback prints 'Received: ' followed by the message's data attribute.

2. Step 2: Substitute the message data value

   When the message data is 'Hello', the print outputs 'Received: Hello'.

3. Final Answer:

   Received: Hello -> Option C

4. Quick Check:

   Prints 'Received: ' + msg.data [OK]

Hint: Callback prints 'Received: ' plus message data [OK]

Common Mistakes:

• Printing just the data without prefix
• Printing the variable name instead of its value
• Confusing string formatting syntax

4.

What is wrong with this ROS 2 Python subscriber code?

def callback(msg):
    print(msg.data)

node.create_subscription(std_msgs.msg.String, 'chatter', callback())

medium

A. Missing message type in create_subscription

B. Queue size argument is missing but required

C. Topic name should be a variable, not a string

D. Callback is called immediately instead of passed as a function

Solution

1. Step 1: Check how callback is passed

   The code uses callback() which calls the function immediately instead of passing the function reference.

2. Step 2: Understand correct callback usage

   We must pass callback without parentheses so it is called on message arrival.

3. Final Answer:

   Callback is called immediately instead of passed as a function -> Option D

4. Quick Check:

   Pass callback function, not call it [OK]

Hint: Pass callback without () to create_subscription [OK]

Common Mistakes:

• Adding parentheses to callback in subscription
• Omitting queue size argument (optional in some versions)
• Using variable instead of string for topic name

5.

You want to create a subscriber node that listens to the topic 'sensor_data' and prints only messages where the data is greater than 10. Which callback function correctly implements this?

def callback(msg):
    # Fill in the condition
    if ____:
        print(f"Data: {msg.data}")

hard

A. msg.data > 10

B. msg.data >= 10

C. msg.data < 10

D. msg.data == 10

Solution

1. Step 1: Understand the requirement

   We want to print messages only if data is greater than 10, so the condition must check msg.data > 10.

2. Step 2: Compare options with condition

   msg.data > 10 matches exactly 'greater than 10'. Others check equal or less, which do not meet the requirement.

3. Final Answer:

   msg.data > 10 -> Option A

4. Quick Check:

   Condition for data > 10 is msg.data > 10 [OK]

Hint: Use > 10 to filter messages with data above 10 [OK]

Common Mistakes:

• Using >= instead of > changes condition
• Using < or == prints wrong messages
• Not adding any condition prints all messages