Send Action Goal

R2026b

Send action goal messages to ROS 2 network

Since R2024a

• 

Send Action Goal ROS 2 block

To add a block to a model, double-click the canvas and start typing the block name. Then, select the block from the list.

Libraries:
ROS Toolbox / ROS 2

Description

The Send Action Goal block enables you to send action goal messages to an action server available in a ROS 2 network. It takes in a Simulink^® non-virtual bus as its Goal input, that corresponds to the specified ROS 2 action type.

To create a ROS 2 action client, create a ROS 2 Blank Message block with class set to Action Goal. The output of this block is connected to the Goal input of the Send Action Goal block. The action client is associated with the node of the Simulink model.

You can assign a ROS 2 callback group to the action client using the Callback group type parameter to control how the ROS 2 executor schedules the action client callbacks relative to other callbacks on the same node. This is useful for preventing deadlocks, enabling concurrent callback execution, improving throughput, reducing jitter, and aligning Simulink simulation behavior with generated C++ code execution semantics.

Note

To monitor an active action goal, you must first create a paired Monitor Action Goal block. The paired block is based on the action parameters specified in the Send Action Goal block.

Ports

Input

Goal — ROS 2 action goal message input

non-virtual bus

ROS 2 action goal message input, specified as a non-virtual bus of the goal message type corresponding to the specified action type.

Data Types: bus

Enable — Boolean value to send action goal if there is no goal running

true | false

Boolean value to send action goal if there is no goal running, specified as 1 (true) or 0 (false). If there is no goal running and the Enable port is true, the block sends any goal message available at Goal input. To check if a goal is running, use the StatusCode output of the paired Monitor Action Goal block.

Data Types: Boolean

Output

UUID — Unique ID dedicated to any goal message

non-virtual bus

Unique ID dedicated to any goal message, specified as a non-virtual bus of message type unique_identifier_msgs/UUID.

Data Types: bus

ErrorCode — Send action goal request status indicator

integer

Send action goal request status indicator, returned as an integer with values in the range [0, 3].

Error Code	Description
0	The action client sent the goal successfully and the action server accepted the goal.
1	The action client sent the goal but the action server rejected the goal.
2	The action client failed to send the goal but the action server is available.
3	The action client failed to send the goal because the action server is not available.

Dependencies

To enable this port, select the Show ErrorCode output port parameter.

Data Types: uint8

Parameters

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

Source — Source for specifying action name

Select from ROS network | Specify your own

Source for specifying the action name:

• Select from ROS network — Use Select... to select an action name and type from a full list of supported ROS 2 actions. The Name and Type parameters are set automatically. You must be connected to a ROS 2 network.

• Specify your own — Enter an action name in Name and specify its type in Type. You must match an action name exactly.

Name — ROS 2 action name

character vector

ROS 2 action name, specified as a character vector. The action name must match an action available on the ROS 2 network.

Type — ROS 2 action type

character vector

ROS 2 action type, specified as a character vector. The action type defines the structure of the goal, result, and feedback messages for the action (for example, example_interfaces/Fibonacci). Each action name has a corresponding action type.

Paired Monitor Action Goal Block — Path to paired Monitor Action Goal block

block path

Path to the Monitor Action Goal block paired with this Send Action Goal block. To create a paired Monitor Action Goal for the first time, select the Create paired Monitor Action Goal block parameter.

After you create a paired Monitor Action Goal block, clicking the path displays and highlights the Monitor Action Goal block in your model.

Tips

For correct action client implementation, use only the Create paired Monitor Action Goal block parameter to create the Monitor Action Goal block associated with this Send Action Goal block. It is not recommended to add a Monitor Action Goal block from the library.

Show ErrorCode output port — Enable error code output port

off (default) | on

Check this box to enable the ErrorCode output.

Callback group type — Type of callback group for action client

Default (default) | Mutually exclusive | Reentrant

Type of ROS 2 callback group to assign to the action client, specified as one of these values:

• Default — Assign the action client to the default callback group of the ROS 2 node. The default callback group is mutually exclusive, which means that only one callback in the group can execute at a time. This is the standard ROS 2 behavior.

• Mutually exclusive — Assign the action client to a named mutually exclusive callback group. Only one callback in this group can execute at a time, but callbacks in different groups can execute concurrently. Specify the group name using the Callback Group Name parameter. Blocks that share a name share a group.

• Reentrant — Assign the action client to a reentrant callback group. Multiple callbacks in this group can execute concurrently. Use this option when your algorithm is thread-safe and you need concurrent callback execution for improved throughput.

  Note

  When using a reentrant callback group:

  • The ROS 2 executor might run multiple instances of the same callback concurrently.

  • Requests or messages might be processed out of order.

  Use reentrant callback groups only when your algorithm is thread-safe and does not depend on strict ordering.

Callback group name — Name of callback group

character vector

Name of the callback group, specified as a character vector. Use this parameter to assign the action client to a specific callback group. Multiple blocks that share the same callback group name belong to the same callback group, allowing you to control which callbacks are grouped together for concurrency management.

Dependencies

To enable this parameter, set the Callback group type parameter to Mutually exclusive.

QoS

Quality of Service (QoS) settings of the action client for establishing communication with the action server. You can set the Goal Service QoS, Result Service QoS, Cancel Service QoS, Feedback Topic QoS, and Status QoS with the following options:

History — Mode of storing goal requests in the queue

Keep last (default) | Keep all

Determines the mode of storing send goal requests in the queue. If the queue fills with requests waiting to be processed, then old requests are dropped to make room for new ones. 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 goal request queue

1 (default) | non-negative scalar integer

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

Reliability — Delivery guarantee of goal requests

Reliable (default) | Best effort

Requirement on delivery guarantee of goal requests, 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 actions.

Durability — Persistence of action goal requests

Volatile (default) | Transient local

Requirement on persistence of the action goal requests, specified as Volatile or Transient local. If Volatile, then requests are not required to persist. If Transient local, then the server requires clients to persist the most recent requests specified by Depth. Volatile setting is recommended to prevent servers from receiving out-of-date requests in the event of a server restart.

Deadline — Maximum amount of time allowed between receiving a goal request and sending goal result

Inf (default) | positive scalar

Maximum amount of time allowed between receiving a goal request and sending a goal result, specified as a positive scalar. The Deadline QoS parameter of action clients sending goal requests must be greater than or equal to the value of the action server Deadline QoS parameter. The default value is Inf, which implies that the expected interval between subsequent messages is infinite.

Lifespan — Length of time a goal request is considered valid

Inf (default) | positive scalar

Length of time a goal request is considered valid, specified as a positive scalar. The block does not process goal requests persisting longer than the specified lifespan in the queue. The default value is Inf, which implies that a goal request is valid for an infinite length of time.

Liveliness — Liveliness check of action server by action client

automatic (default)

Liveliness check of action server by action client, specified as automatic. This parameter is a measure of whether the action server is still alive.

Liveliness set to automatic implies that after the action server has sent a goal response to the action client, the client considers the server to be alive for an additional Lease Duration.

Lease Duration — Maximum amount of time before an action client has to assert liveliness

Inf (default) | positive scalar

Maximum amount of time before an action client has to assert liveliness, specified as a positive scalar. The Lease Duration QoS parameter of action clients sending goal requests must be greater than or equal to the value of the action server Lease Duration QoS parameter. The default value is Inf, which implies that the action client can assert its liveliness for an infinite amount of time.

Note

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

Algorithms

On each simulation step, the Send Action Goal block checks whether a goal is active, leading to one of these outcomes:

• If the goal is active, the block ignores any goal message available at the Goal input and outputs the active goal UUID as a Simulink non-virtual bus of unique_identifier_msgs/UUID message type.

• If there is no goal running and the Enable port is true, the block sends any goal message available at the Goal input and outputs the new goal UUID as a Simulink non-virtual bus of unique_identifier_msgs/UUID message type.

• If there is no goal running and the Enable port is false, the block ignores any goal message available at the Goal input and outputs the default goal UUID (empty message) as a Simulink non-virtual bus of unique_identifier_msgs/UUID message type.

Extended Capabilities

C/C++ Code Generation

Generate C and C++ code using Simulink® Coder™.

Usage notes and limitations:

• The generated action client from the Send Action Goal block follows rate-based execution and not event-driven execution.

• The Callback group type and Callback group name parameters are honored in generated code. The generated ROS 2 node assigns the action client to the specified callback group, controlling how the executor schedules the action client callbacks relative to other callbacks on the same node.

Version History

Introduced in R2024a

R2026b: Assign callback groups to control concurrency of action client callbacks

The Send Action Goal block in ROS 2 now supports callback group assignment through the new Callback group type and Callback group name parameters. You can assign the action client to the default callback group, a named mutually exclusive callback group, or a named reentrant callback group. These options allow you to control how the ROS 2 executor schedules the action client callbacks relative to other callbacks on the same node. Use callback groups to prevent deadlocks, enabling concurrent callback execution, improving throughput, reducing jitter, and aligning Simulink simulation behavior with generated C++ code execution semantics. The callback group selection is honored in both simulation and generated code.