Request-response communication model in ROS - Deep Dive

Overview - Request-response communication model

What is it?

The request-response communication model is a way for two parts of a system to talk by one part asking for something (request) and the other part answering (response). In ROS, this model is used to let nodes ask other nodes to perform tasks and get results back. It works like a conversation where one side waits for the other to reply before continuing. This helps organize communication clearly and predictably.

Why it matters

Without this model, nodes would have to guess when to send or receive data, making communication confusing and error-prone. The request-response pattern ensures that messages are paired and synchronized, so nodes know exactly when a task is done and what the result is. This makes robot programs more reliable and easier to understand, especially when tasks depend on each other.

Where it fits

Before learning this, you should understand basic ROS concepts like nodes, topics, and messages. After this, you can explore more complex communication patterns like action servers for long-running tasks or asynchronous messaging. This model is a foundation for building clear, synchronous interactions in ROS systems.

Mental Model

Core Idea

Request-response communication is like a phone call where one node asks a question and waits for the answer before moving on.

Think of it like...

Imagine ordering food at a restaurant: you tell the waiter what you want (request), then wait until the waiter brings your meal (response) before you start eating.

┌─────────────┐       request       ┌─────────────┐
│ Requesting  │────────────────────▶│ Responding  │
│ Node        │                     │ Node        │
└─────────────┘       response      └─────────────┘
         ◀────────────────────

This shows a clear two-way exchange: one side asks, the other replies.

Build-Up - 7 Steps

1

Foundation

Understanding ROS Nodes and Messages

Concept: Learn what nodes and messages are in ROS, the building blocks for communication.

In ROS, a node is a program that does some work, like sensing or controlling. Nodes talk by sending messages, which are structured pieces of data. Messages travel over topics, which are like channels. Before request-response, you need to know how nodes send and receive messages.

Result

You can identify nodes and understand how they exchange data using messages.

Understanding nodes and messages is essential because request-response builds on this basic communication.

2

Foundation

Basics of Synchronous Communication

Concept: Introduce the idea of waiting for a reply before continuing.

Synchronous communication means one side sends a request and waits until it gets a response before doing anything else. This is different from just sending messages without waiting. It ensures the requester knows the task is done and what the result is.

Result

You grasp why waiting for a response is important to keep things in order.

Knowing synchronous communication helps you see why request-response is useful for tasks that need confirmation.

3

Intermediate

ROS Services: Implementing Request-Response

🤔Before reading on: do you think ROS services allow multiple requests at the same time or only one at a time? Commit to your answer.

Concept: ROS services provide a built-in way to do request-response communication between nodes.

A ROS service has two parts: a service server that waits for requests and a service client that sends requests. The client calls the service with a request message and waits for the server to reply with a response message. This is done using special service message types that define the request and response data.

Result

You can create a service server and client in ROS that talk using request-response.

Understanding ROS services reveals how request-response is formally structured and managed in ROS.

4

Intermediate

Service Message Types and Definitions

🤔Before reading on: do you think service messages combine request and response in one file or separate files? Commit to your answer.

Concept: Service messages define both request and response data in a single file with two parts.

In ROS, a service message file has two sections separated by '---'. The first part defines the request fields, and the second part defines the response fields. This clear structure helps ROS generate code to handle both sides of the communication automatically.

Result

You understand how to design the data exchanged in request-response calls.

Knowing the message structure helps you create precise and effective service interfaces.

5

Intermediate

Client-Server Interaction Flow

Concept: Learn the step-by-step process of how a client and server communicate in ROS services.

1. Client sends a request message to the server. 2. Server receives the request and processes it. 3. Server sends back a response message. 4. Client receives the response and continues. This flow is blocking for the client, meaning it waits until the response arrives.

Result

You can predict how data moves and when nodes wait or proceed.

Understanding this flow clarifies how synchronous communication is enforced in ROS services.

6

Advanced

Handling Service Timeouts and Failures

🤔Before reading on: do you think a service client waits forever for a response or can it stop waiting? Commit to your answer.

Concept: Learn how to manage cases when the server is slow or unavailable.

ROS service clients can set timeouts to avoid waiting forever. If the server does not respond in time, the client can handle the failure gracefully, like retrying or reporting an error. This is important for robust robot behavior where some services might fail or be busy.

Result

You can write clients that handle delays and failures without freezing your program.

Knowing how to handle timeouts prevents your robot from getting stuck waiting indefinitely.

7

Expert

Limitations and Alternatives to Request-Response

🤔Before reading on: do you think request-response is ideal for long-running tasks or short quick queries? Commit to your answer.

Concept: Explore when request-response is not the best choice and what to use instead.

Request-response is great for quick, simple queries but not for long tasks because the client waits and blocks. For long-running or cancelable tasks, ROS provides action servers that allow feedback and preemption. Also, asynchronous messaging with topics can be better for continuous data streams.

Result

You know when to choose request-response and when to use other communication patterns.

Understanding the limits of request-response helps you design efficient and responsive robot systems.

Under the Hood

Underneath, ROS services use a TCPROS connection where the client opens a TCP connection to the server. The client sends a serialized request message, the server processes it, then sends back a serialized response. The client blocks waiting for this response. ROS automatically generates code to handle message serialization, connection setup, and teardown, making the process seamless to the user.

Why designed this way?

This design was chosen to provide a simple, synchronous communication method that fits many robot control needs. Using TCP ensures reliable delivery and ordering of messages. The blocking call model matches common programming patterns and makes it easy to write code that waits for results. Alternatives like asynchronous messaging exist but are more complex to manage.

Client Node
  │
  │ TCP Connection (request)
  ▼
Service Server Node
  │
  │ TCP Connection (response)
  ▲
Client Node

This shows a two-way TCP connection where the client sends a request and waits for the server's response.

Myth Busters - 4 Common Misconceptions

Quick: Do you think a ROS service client can send multiple requests without waiting for responses? Commit to yes or no.

Common Belief: A service client can send many requests at once without waiting for each response.

Reality: A ROS service client sends one request and waits for the response before sending another. It is a synchronous, blocking call.

Why it matters: Believing otherwise can lead to code that tries to send multiple requests simultaneously, causing errors or unexpected behavior.

Quick: Do you think request-response communication is suitable for streaming sensor data? Commit to yes or no.

Common Belief: Request-response is good for continuous data streams like sensor readings.

Reality: Request-response is not suitable for continuous or high-frequency data. Topics with publishers and subscribers are better for streaming data.

Why it matters: Using request-response for streaming can cause delays and block the system, reducing performance.

Quick: Do you think a service server can handle multiple requests at the same time? Commit to yes or no.

Common Belief: A service server can process many requests simultaneously in parallel.

Reality: By default, a ROS service server processes requests one at a time, sequentially.

Why it matters: Expecting parallel handling can cause performance bottlenecks if the server is slow, leading to delays.

Quick: Do you think the request and response messages are defined separately in ROS? Commit to yes or no.

Common Belief: Request and response messages are defined as separate message files.

Reality: They are defined together in a single service file with two parts separated by '---'.

Why it matters: Misunderstanding this can cause confusion when creating service definitions and lead to errors in message generation.

Expert Zone

1

ROS services use TCP connections that are established and closed for each call, which can add overhead compared to persistent connections in other protocols.

2

Service callbacks run in the server's thread, so long processing can block other requests unless handled with multi-threaded spinning.

3

The blocking nature of service clients means they should not be called from real-time or high-frequency loops to avoid delays.

When NOT to use

Avoid request-response services for long-running tasks, streaming data, or when you need non-blocking calls. Instead, use ROS actions for tasks with feedback and cancelation, or topics for continuous data flow.

Production Patterns

In production, services are used for configuration queries, triggering immediate actions, or getting status info. Complex behaviors combine services with topics and actions to balance responsiveness and control.

Connections

Client-Server Architecture

Request-response in ROS is a specific example of the client-server pattern used in software engineering.

Understanding client-server basics helps grasp how ROS services organize communication between nodes.

HTTP Protocol

Request-response in ROS is similar to how web browsers request pages from servers using HTTP.

Knowing HTTP's request-response cycle clarifies why ROS services block waiting for replies and how data is exchanged.

Human Conversations

Request-response mimics how people ask questions and wait for answers in dialogue.

Recognizing this natural pattern helps design intuitive communication flows in robotics.

Common Pitfalls

#1 Calling a service client inside a high-frequency loop causing delays.

Wrong approach:

while (ros::ok()) {
client.call(srv);
// do other work
}

Correct approach:

if (need_to_call_service) {
client.call(srv);
// handle response
}

Root cause:

Misunderstanding that service calls block and should not be called repeatedly without control.

#2 Defining request and response messages in separate files causing build errors.

Wrong approach:

Creating two separate .msg files for request and response instead of one .srv file.

Correct approach:

Defining a single .srv file with request fields, then '---', then response fields.

Root cause:

Not knowing ROS service message format combines request and response in one file.

#3 Expecting service servers to handle multiple requests in parallel without extra setup.

Wrong approach:

Writing a service callback that takes a long time without multi-threaded spinning.

Correct approach:

Using AsyncSpinner or multi-threaded spinner to allow concurrent service handling.

Root cause:

Assuming service servers are automatically concurrent when they are not.

Key Takeaways

Request-response communication in ROS uses services where one node asks and waits for another node's answer.

This model is synchronous and blocking, making it suitable for quick queries but not for long or continuous tasks.

Service messages combine request and response data in one file, simplifying interface design.

Understanding the client-server flow and limitations helps build reliable and efficient robot programs.

Knowing when to use services versus topics or actions is key to designing good ROS communication.

Practice

1. In ROS, what does the request-response communication model primarily allow?

easy

A. One node sends a request and waits for a reply from another node

B. Nodes continuously publish data without expecting a reply

C. Nodes broadcast messages to all other nodes simultaneously

D. Nodes store data locally without communication

Solution

1. Step 1: Understand the request-response model in ROS

   This model involves one node sending a request message and waiting for a response from another node.

2. Step 2: Compare options with this model

   Only One node sends a request and waits for a reply from another node describes this direct ask-and-reply behavior, while others describe different communication types.

3. Final Answer:

   One node sends a request and waits for a reply from another node -> Option A

4. Quick Check:

   Request-response = direct ask and reply [OK]

Hint: Request-response means ask first, then wait for answer [OK]

Common Mistakes:

• Confusing request-response with continuous publishing
• Thinking request-response is broadcasting
• Assuming no reply is needed

2. Which of the following is the correct way to define a ROS service server in Python using the request-response model?

easy

A. service = rospy.Service('service_name', ServiceType, handler_function)

B. service = rospy.Publisher('service_name', ServiceType, handler_function)

C. service = rospy.Subscriber('service_name', ServiceType, handler_function)

D. service = rospy.Client('service_name', ServiceType, handler_function)

Solution

1. Step 1: Recall ROS Python service server syntax

   In ROS, a service server is created using rospy.Service with the service name, type, and handler function.

2. Step 2: Identify correct function

   Only rospy.Service matches this pattern; Publisher and Subscriber are for topics, Client is not a rospy function.

3. Final Answer:

   service = rospy.Service('service_name', ServiceType, handler_function) -> Option A

4. Quick Check:

   Service server uses rospy.Service [OK]

Hint: Service server uses rospy.Service, not Publisher or Subscriber [OK]

Common Mistakes:

• Using Publisher or Subscriber instead of Service
• Confusing client and server creation
• Wrong function names like rospy.Client

3. Given this ROS Python service client code snippet, what will be printed if the service responds with response.result = 42?

import rospy
from example.srv import AddTwoInts

def call_service():
    rospy.wait_for_service('add_two_ints')
    try:
        add_two_ints = rospy.ServiceProxy('add_two_ints', AddTwoInts)
        response = add_two_ints(20, 22)
        print(response.result)
    except rospy.ServiceException as e:
        print("Service call failed", e)

call_service()

medium

A. Service call failed

B. 42

C. 20

D. None

Solution

1. Step 1: Understand the service client call

   The client waits for the service, calls it with 20 and 22, and expects a response with a 'result' attribute.

2. Step 2: Analyze the response printing

   The code prints response.result, which is given as 42 in the question.

3. Final Answer:

   42 -> Option B

4. Quick Check:

   Print response.result = 42 [OK]

Hint: Prints the response.result value returned by the service [OK]

Common Mistakes:

• Confusing request parameters with response
• Expecting print of input values instead of response
• Assuming exception without error

4. What is wrong with this ROS Python service server code snippet?

import rospy
from example.srv import Multiply

def handle_multiply(req):
    return req.a * req.b

rospy.init_node('multiply_server')
service = rospy.Service('multiply', Multiply, handle_multiply)
rospy.spin()

medium

A. The service type Multiply is not imported correctly

B. The service name cannot be 'multiply'

C. The handler must return a response object, not just a number

D. rospy.spin() is missing

Solution

1. Step 1: Check the handler function return type

   In ROS services, the handler must return a response message object, not a raw value.

2. Step 2: Identify the error in return statement

   Returning req.a * req.b (a number) is incorrect; it should return MultiplyResponse(req.a * req.b) or equivalent.

3. Final Answer:

   The handler must return a response object, not just a number -> Option C

4. Quick Check:

   Handler returns response object, not raw value [OK]

Hint: Handler must return response message object, not raw data [OK]

Common Mistakes:

• Returning raw values instead of response objects
• Forgetting to import response message class
• Missing rospy.spin() (though present here)

5. You want to implement a ROS service that returns the sum of two integers only if both are positive; otherwise, it returns zero. Which handler function correctly implements this request-response logic?

hard

A. def handle_sum(req):
return SumTwoIntsResponse(req.a + req.b)

B. def handle_sum(req):
return SumTwoIntsResponse(req.a + req.b if req.a > 0 or req.b > 0 else 0)

C. def handle_sum(req):
if req.a > 0 or req.b > 0:
return SumTwoIntsResponse(req.a + req.b)
else:
return SumTwoIntsResponse(0)

D. def handle_sum(req):
if req.a > 0 and req.b > 0:
return SumTwoIntsResponse(req.a + req.b)
else:
return SumTwoIntsResponse(0)

Solution

1. Step 1: Understand the condition for sum

   The sum should be returned only if both req.a and req.b are positive (greater than zero).

2. Step 2: Check each option's condition logic

   def handle_sum(req): if req.a > 0 and req.b > 0: return SumTwoIntsResponse(req.a + req.b) else: return SumTwoIntsResponse(0) uses 'and' to check both positive, returning sum or zero correctly. def handle_sum(req): return SumTwoIntsResponse(req.a + req.b if req.a > 0 or req.b > 0 else 0) uses 'or' incorrectly and missing parentheses in ternary. def handle_sum(req): if req.a > 0 or req.b > 0: return SumTwoIntsResponse(req.a + req.b) else: return SumTwoIntsResponse(0) uses 'or' which is wrong logic. def handle_sum(req): return SumTwoIntsResponse(req.a + req.b) always returns sum ignoring condition.

3. Final Answer:

   def handle_sum(req): if req.a > 0 and req.b > 0: return SumTwoIntsResponse(req.a + req.b) else: return SumTwoIntsResponse(0) -> Option D

4. Quick Check:

   Both positive check with 'and' = def handle_sum(req): if req.a > 0 and req.b > 0: return SumTwoIntsResponse(req.a + req.b) else: return SumTwoIntsResponse(0) [OK]

Hint: Use 'and' to check both positive before summing [OK]

Common Mistakes:

• Using 'or' instead of 'and' for both positive check
• Returning sum without condition
• Incorrect ternary syntax in return