Why topics enable decoupled communication in ROS - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a ROS publisher that sends messages on a topic.

ROS

pub = node.create_publisher(std_msgs.msg.String, '[1]', 10)

Drag options to blanks, or click blank then click option'

Aservice_call

Blistener

C/chatter

Daction_server

Attempts:

3 left

💡 Hint

Common Mistakes

Using service or action names instead of topic names.

Using subscriber names as topic names.

The topic name '/chatter' is used to publish messages. This enables decoupled communication by letting publishers and subscribers connect via this topic.

2fill in blank

medium

Complete the code to subscribe to a topic and receive messages.

ROS

sub = node.create_subscription(std_msgs.msg.String, '/chatter', [1], 10)

Drag options to blanks, or click blank then click option'

Alistener_callback

Bsend_message

Cpublish_callback

Dservice_handler

Attempts:

3 left

💡 Hint

Common Mistakes

Using publisher functions as callbacks.

Using service handlers instead of callbacks.

The subscriber needs a callback function to process incoming messages. 'listener_callback' is the function called when a message arrives.

3fill in blank

hard

Fix the error in the code to publish a message on the topic.

ROS

msg = std_msgs.msg.String()
msg.data = 'Hello ROS'
pub.[1](msg)

Drag options to blanks, or click blank then click option'

Apublish

Bsend

Ccall

Dwrite

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'send' instead of 'publish'.

Trying to call non-existent methods.

The correct method to send a message on a ROS topic is 'publish'. Other methods do not exist or cause errors.

4fill in blank

hard

Fill both blanks to create a topic subscriber with a callback that prints the message data.

ROS

def [1](msg):
    print(msg.[2])
sub = node.create_subscription(std_msgs.msg.String, '/chatter', [1], 10)

Drag options to blanks, or click blank then click option'

Alistener_callback

Bdata

Cmsg

Dcallback

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching callback function names.

Accessing wrong message attributes.

The callback function is named 'listener_callback'. The message data is accessed via 'msg.data'.

5fill in blank

hard

Fill all three blanks to create a publisher, a message, and publish it on the topic.

ROS

pub = node.create_publisher(std_msgs.msg.String, [1], 10)
msg = std_msgs.msg.String()
msg.[2] = 'Decoupled communication'
pub.[3](msg)

Drag options to blanks, or click blank then click option'

A/chatter

Bdata

Cpublish

Dsend

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'send' instead of 'publish'.

Wrong topic names or message attributes.

The topic name is '/chatter'. The message content is set with 'data'. The method to send the message is 'publish'.

Practice

1. Why do ROS topics enable decoupled communication between nodes?

easy

A. Because nodes send and receive messages without knowing each other's identity

B. Because topics require nodes to share the same code

C. Because topics force nodes to run on the same machine

D. Because topics require nodes to be started in a specific order

Solution

1. Step 1: Understand how nodes communicate via topics

   Nodes publish or subscribe to topics without direct references to each other.

2. Step 2: Recognize decoupling in communication

   This means nodes do not need to know who is sending or receiving messages, enabling flexibility.

3. Final Answer:

   Because nodes send and receive messages without knowing each other's identity -> Option A

4. Quick Check:

   Decoupled communication = nodes unaware of each other [OK]

Hint: Topics hide sender/receiver details for loose coupling [OK]

Common Mistakes:

• Thinking nodes must share code to communicate
• Assuming nodes must run on the same machine
• Believing nodes need a start order

2. Which of the following is the correct way to subscribe to a topic in ROS using Python?

easy

A. rospy.Subscriber('topic_name', MessageType, callback_function)

B. rospy.Publisher('topic_name', MessageType, callback_function)

C. rospy.Subscribe('topic_name', callback_function)

D. rospy.listen('topic_name', MessageType)

Solution

1. Step 1: Recall ROS Python subscription syntax

   The correct syntax uses rospy.Subscriber with topic name, message type, and callback.

2. Step 2: Identify incorrect options

   Publisher is for sending, not subscribing; other options use wrong method names.

3. Final Answer:

   rospy.Subscriber('topic_name', MessageType, callback_function) -> Option A

4. Quick Check:

   Subscribe syntax = rospy.Subscriber(...) [OK]

Hint: Subscriber uses rospy.Subscriber(topic, type, callback) [OK]

Common Mistakes:

• Confusing Publisher and Subscriber functions
• Using incorrect method names like Subscribe or listen
• Omitting message type argument

3. Given the following ROS Python code snippet, what will be printed when a message is published to 'chatter' topic?

import rospy
from std_msgs.msg import String

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

rospy.init_node('listener')
rospy.Subscriber('chatter', String, callback)
rospy.spin()

medium

A. Error: callback function missing

B. Received: None

C. No output because node is not publishing

D. Received:

Solution

1. Step 1: Analyze subscriber callback behavior

   The callback prints 'Received: ' plus the message data when a message arrives on 'chatter'.

2. Step 2: Understand message flow

   When a message is published to 'chatter', the callback runs and prints the message content.

3. Final Answer:

   Received: <message content> -> Option D

4. Quick Check:

   Callback prints message data on topic message [OK]

Hint: Callback prints message data when topic message arrives [OK]

Common Mistakes:

• Thinking node must publish to print output
• Assuming callback is missing or not called
• Expecting None instead of actual message data

4. You wrote a ROS node to subscribe to a topic but it never receives messages. Which of these is a likely cause?

medium

A. The publisher node is running on a different machine

B. The topic name is correct but message type is mismatched

C. The subscriber node did not call rospy.spin() to keep running

D. The subscriber node uses rospy.Publisher instead of rospy.Subscriber

Solution

1. Step 1: Check subscriber node lifecycle

   Without rospy.spin(), the node exits immediately and misses messages.

2. Step 2: Evaluate other options

   Mismatched message types cause errors but usually show warnings; different machines can communicate if networked; using Publisher instead of Subscriber is a coding error but not the most common cause here.

3. Final Answer:

   The subscriber node did not call rospy.spin() to keep running -> Option C

4. Quick Check:

   Missing rospy.spin() stops subscriber from receiving [OK]

Hint: Always call rospy.spin() in subscriber nodes [OK]

Common Mistakes:

• Ignoring the need for rospy.spin()
• Assuming network issues without checking code
• Confusing Publisher and Subscriber roles

5. In a complex robot system, why is using ROS topics for communication better than direct node-to-node service calls?

hard

A. Topics require nodes to know each other's IP addresses, improving security

B. Topics allow multiple nodes to publish and subscribe independently, enabling flexible data sharing

C. Topics force nodes to run synchronously, ensuring ordered execution

D. Topics limit communication to only one publisher and one subscriber

Solution

1. Step 1: Compare topics and services in ROS

   Topics support many-to-many communication asynchronously, while services are one-to-one and synchronous.

2. Step 2: Understand benefits of topics for complex systems

   Multiple nodes can publish or subscribe without tight coupling, making the system flexible and scalable.

3. Final Answer:

   Topics allow multiple nodes to publish and subscribe independently, enabling flexible data sharing -> Option B

4. Quick Check:

   Topics = many-to-many, asynchronous communication [OK]

Hint: Topics support many-to-many async communication for flexibility [OK]

Common Mistakes:

• Thinking topics require knowing node IPs
• Assuming topics force synchronous execution
• Believing topics limit to single publisher/subscriber