Main Content

Receive Service Request

Receive service request from ROS 2 network

Since R2024a

expand all in page
  • Receive Service Request block icon.

Libraries:
ROS Toolbox / ROS 2

Description

The Receive Service Request block enables you to receive a ROS 2 service request message from a service client, process it in the model to construct an appropriate response, and then send the response to the client using a Send Service Response block. Thus, you can use the Receive Service Request and Send Service Response blocks in the same model to implement a ROS 2 service server in Simulink®. The service server is associated with the node of the Simulink model.

On each simulation step, the Receive Service Request block checks if a new service request has been sent by a client. If a new service request is available, the block retrieves it and outputs a non-virtual bus which corresponds to the service request message type. If the block does not receive a service request at a time step, it outputs the last service request message received.

Specify the name for your ROS 2 service, the service type, and the quality of service (QoS) parameters in the block mask. QoS parameters for this block must be compatible with the service clients to receive requests and send responses.

Note

For each Receive Service Request you add to a model, you must click Click to create paired Send Response block in the block mask to create a paired Send Service Response block. Do not add a Send Service Response block from the library.

Examples

Create ROS 2 Service Server in Simulink

Create ROS 2 Service Server in Simulink

Set up a ROS 2 service server in Simulink® which provides the vector cross product as response for any two input vectors. You then create a service client, connect to the service server and send a service request with two input vectors.

Open Live Script

Ports

Output

expand all

New service request indicator, returned as a logical. If the output is 1, then a new service request was received since the last sample hit. You can use this output to trigger subsystems for processing new messages received in the ROS 2 network.

Data Types: Boolean

Service request message, returned as a non-virtual bus corresponding to the service request type. The service request message type depends on the service type specified in the Service Type parameter.

Data Types: bus

Default response message, returned as a non-virtual bus corresponding to the default response message type.

Dependencies

  • To enable this output port, select the Show Default Response output port parameter.

Data Types: bus

Parameters

expand all

To edit block parameters interactively, use the Property Inspector. From the Simulink Toolstrip, on the Simulation tab, in the Prepare gallery, select Property Inspector.

Main

Service name, specified as a character vector. This is the name of the service server which clients can then use to connect and send service requests.

Service type, specified as a character vector. Each service name has a corresponding type. Click the Select button to select from a full list of supported ROS 2 service types.

If you are using a custom service type, first build the associated service definitions using the ros2genmsg function. Then, you can specify your custom service type using the Select button.

Path to the Send Service Response block paired with this Receive Service Request block. To create a paired Send Service Response for the first time, click Create paired Send Response block.

After you create a paired Send Service Response block, clicking the path displays and highlights the Send Service Response block in your model.

Tips

  • For correct service server implementation, only use Click to create paired Send Response block to create the Send Service Response associated with this Receive Service Request block. Do not add a Send Service Response block from the library.

Interval between outputs, specified as a scalar. In simulation, the sample time follows simulation time and not actual wall-clock time.

This default value indicates that the block sample time is inherited.

For more information about the inherited sample time type, see Specify Sample Time (Simulink).

Check this box to enable the DefaultResp output.

Quality of Service (QoS)

Determines the mode of storing requests in the queue. If the queue fills with requests waiting to be processed, then old requests will be dropped to make room for new. If set to Keep last, the queue stores the number of requests set by the Depth parameter. If set to Keep all, the queue stores all requests up to the MATLAB® resource limits.

Size of the request queue in number of requests stored in the queue, specified as a non-negative scalar integer.This only applies when History is set to Keep last.

Requirement on delivery guarantee of request and response, specified as Reliable or Best effort. If Reliable, then delivery is guaranteed, but may retry multiple times. If Best effort, then attempt delivery and do not retry. Reliable setting is recommended for services.

Note

The quality of service settings must be compatible between service servers and clients for a connection to be made.

Requirement on persistence of the client, specified as Volatile or Transient local. If Volatile, then requests are not required to persist. If Transient local, then the server will require clients to persist and receive responses for the number of previous requests specified by Depth. Volatile setting is recommended to prevent servers from receiving out of date requests in the event of a server restart.

Note

The quality of service settings must be compatible between service servers and clients for a connection to be made.

Maximum amount of time allowed between receiving a service request and sending a response, specified as a positive scalar. The Deadline QoS parameter of service clients sending requests to the block must be greater than or equal to the value of this parameter.

The default value is Inf which implies that after the service server receives a service request, it can wait for an infinite period of time before sending response to that request.

Note

The quality of service settings must be compatible between service servers and clients for a connection to be made.

Length of time a service request is considered valid, specified as a positive scalar. The block does not process service requests persisting longer than the specified lifespan in the queue.

The default value is Inf which implies that a service request received by service server is considered valid for infinite period of time.

Note

The quality of service settings must be compatible between service servers and clients for a connection to be made.

Level of liveliness reporting provided by the block and expected from the connected service clients, specified as automatic.

Liveliness set to automatic implies that after the block receives a service request from a connected client, the block considers that client to be alive for another Lease Duration.

Note

The quality of service settings must be compatible between service servers and clients for a connection to be made.

Maximum amount of time before which a connected service client has to assert liveliness, specified as a positive scalar.

The default value is Inf which implies that the service client connected to the server can assert liveliness for infinite period of time.

Note

The quality of service settings must be compatible between service servers and clients for a connection to be made.

Extended Capabilities

Version History

Introduced in R2024a

See Also

Blocks

Objects