Receive Service Request

Receive service request from ROS 2 network

Since R2024a

Libraries:
ROS Toolbox / ROS 2

Description

Use the Receive Service Request and Send Service Response blocks in the same model to implement a ROS 2 service server in Simulink^®. 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. The service server is associated with the ROS 2 node of the Simulink model.

Depending on the parameter, the block can either check for new requests at each simulation step, outputting the request if available or repeating the last request if none arrives, or process requests immediately upon arrival, triggering an event signal to execute a Function-Call Subsystem asynchronously.

Depending on the Process Service Request parameter setting, the block either check for new requests at each simulation step or processes them immediately upon arrival. In the latter case, it triggers an event to handle the request asynchronously. This asynchronous mode is supported only for code generation.

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 Paired Send Response Block in the block mask to create a paired Send Service Response block. Adding a Send Service Response block from the library is not recommended.

Examples

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

Plan Excavator Trajectory in ROS 2 Using Asynchronous Service Server

Use asynchronous ROS 2 service server in Simulink to plan and execute collision-free trajectories for a simulated autonomous excavator.

Open Live Script

Ports

Output

expand all

IsNew — New service request indicator
`0` | `1`

Indicates whether a new service request was received during the current sample time, returned as a logical. When the Process Service Request parameter is set to At sample time, this output returns 1 if a new service request was received since the last sample hit, and 0 otherwise. You can use this signal to trigger subsystems for synchronous processing of requests at the block’s sample time. If Process Service Request is set to Immediately on arrival, this port is not available, and the block instead provides the OnReqArrivalEvent output port for asynchronous processing.

Dependencies

To enable this output port, set the Process Service Request parameter to At sample time.

Data Types: Boolean

OnReqArrivalEvent — Event signal to trigger execution of subsystems when a new service request arrives
function-call signal

Event signal to trigger execution of subsystems when a new service request arrives, specified as a function-call signal. When the Process Service Request parameter is set to Immediately on arrival, this output port emits a function-call signal whenever a service request is received. Connect the port to a Function-Call Subsystem to process requests asynchronously upon arrival. If Process Service Request is set to At sample time, this port is not available, and the block instead provides the IsNew indicator output.

Dependencies

To enable this output port, set the Process Service Request parameter to Immediately on arrival.

Data Types: bus

Req — Service request message
non-virtual bus

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

DefaultResp — Default response message
non-virtual 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

Name — Service name
character vector

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.

Type — Service type
character vector

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.

Show Default Response output port — Enable default response output port
`on` (default) | `off`

Check this box to enable the DefaultResp output.

Process Service Request — Specify when service server processes incoming service requests
`At sample time` (default) | `Immediately on arrival`

Use this parameter to specify when the service server processes incoming service requests. Specify the parameter as one of these two options:

At sample time — Process service requests in sync with the sample time of the block.
Immediately on arrival — Process service requests asynchronously as soon as they arrive. Enabling asynchronous behavior disables the Sample time parameter in the dialog box.

Paired Send Response Block — Path to paired Send Service Response block
block path

Path to the Send Service Response block paired with this Receive Service Request block, specified as the following options:

Create paired Send Response block inside Enable subsystem — Set the Process Service Request parameter to At sample time to enable this option. Click it to create a Enable subsystem that contains a paired Send Service Response block. In this case, the callback in the service server runs the response logic inside this subsystem, triggered by the IsNew output port. The response block executes only when a new request arrives, keeping processing aligned with the block’s sample time.
Create paired Send Response block inside Function-Call subsystem — Set the Process Service Request parameter to Immediately on arrival to enable this option. Click it to create a Function-Call subsystem that contains a paired Send Service Response block. In this case, the callback in the service server runs the response logic inside this subsystem, triggered by the OnReqArrivalEvent output port. The response block executes as soon as a new request arrives, keeping processing asynchronous with request arrival.

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

Tips

For correct service server implementation, only use the specified option from the block mask to create the Send Service Response associated with this Receive Service Request block. Adding a Send Service Response block from the library is not recommended.

Sample time — Interval between outputs
`–1` (default) | scalar

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).

Quality of Service (QoS)

History — Mode of storing requests in the queue
`Keep last` (default) | `Keep all`

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.

Depth — Size of the request queue
`1` (default) | `non-negative scalar integer`

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.

Reliability — Delivery guarantee of requests
`Reliable` (default) | `Best effort`

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