Publish

Send messages to ROS 2 network

expand all in page
  • Publish ROS 2 block

Libraries:
ROS Toolbox / ROS 2

Description

The Publish block takes in as its input a Simulink® non-virtual bus that corresponds to the specified ROS 2 message type and publishes it to the ROS 2 network. It uses the node of the Simulink model to create a ROS 2 publisher for a specific topic. This node is created when the model runs and is deleted when the model terminates. If the model does not have a node, the block creates one.

On each sample hit, the block converts the Msg input from a Simulink bus signal to a ROS 2 message and publishes it. The block does not distinguish whether the input is a new message but instead publishes it on every sample hit. For simulation, this input is a MATLAB® ROS 2 message. In code generation, it is a C++ ROS 2 message.

Quality of Service (QoS) events related to different QoS policies trigger default warnings for Publish block. For more information on the different QoS events and the triggered warnings respectively, see QoS Events section in Manage Quality of Service Policies in ROS 2 example.

In generated code, ROS 2 nodes created by this block can use loaned messages for publishing, which enable zero-copy data transfer through shared memory. This reduces processing overhead and improves throughput for large or frequent messages. Loaned message support is automatically applied in both local and remote deployments but can be toggled with the environment variable ROS_DISABLE_LOANED_MESSAGES, by setting it to 0 for enabling and 1 for disabling.

Currently, only selected RMW implementations support laoned messages, such as Fast DDS. To achieve true zero-copy communication, you must enable shared memory in the middleware by configuring the DEFAULT_FASTRTPS_PROFILES.xml file:

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <data_writer profile_name="default publisher profile" is_default_profile="true">
        <qos>
            <publishMode>
                <kind>ASYNCHRONOUS</kind>
            </publishMode>
            <data_sharing>
                <kind>AUTOMATIC</kind>
            </data_sharing>
        </qos>
        <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
    </data_writer>

    <data_reader profile_name="default subscription profile" is_default_profile="true">
        <qos>
            <data_sharing>
                <kind>AUTOMATIC</kind>
            </data_sharing>
        </qos>
        <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
    </data_reader>
</profiles>

If a message type does not support loaning (for example, variable-length arrays or strings), the system issues a runtime warning and falls back to regular message handling.

Ports

Input

expand all

ROS message, specified as a nonvirtual bus. To specify the type of ROS message, use the Message type parameter.

Data Types: bus

Parameters

expand all

Main

Source for specifying the topic name, specified as one of the following:

  • Select from ROS network — Use Select to select a topic name. The Topic and Message type parameters are set automatically. You must be connected to a ROS network.

  • Specify your own — Enter a topic name in Topic and specify its message type in Message type. You must match a topic name exactly.

Topic name to publish to, specified as a string. When Topic source is set to Select from ROS network, use Select to select a topic from the ROS network. You must be connected to a ROS 2 network to get a list of topics. Otherwise, set Topic source to Specify your own and specify the topic you want.

ROS message type, specified as a string. Use Select to select from a full list of supported ROS messages. Service message types are not supported and are not included in the list.

Quality of Service (QoS)

Determines the mode of storing messages in the queue. The queued messages will be sent to late-joining subscribers. If the queue fills with messages waiting to be processed, then old messages will be dropped to make room for new. If set to 'keeplast', the queue stores the number of messages set by the Depth parameter. If set to 'keepall', the queue stores all messages up to the MATLAB resource limits.

Number of messages stored in the message queue when History is set to Keep last.

Affects the guarantee of message delivery. If Reliable, then delivery is guaranteed, but may retry multiple times. If Best effort, then attempt delivery and do not retry.

Affects persistence of messages in publishers, which allows late-joining subscribers to receive the number of old messages specified by Depth. If Volatile, then messages do not persist. If Transient local, then publisher will persist most recent messages.

Defines the expected interval for publishing consecutive messages to a topic, specified as a positive scalar. It sets the duration permitted between messages.

The default value is Inf which implies the message can be published and received without being considered as expired, for an infinite duration of time. If Lifespan is set to 5, it means that a message is considered valid for 5 seconds after being published. If subscriber has not received the message within that time frame, the message is considered expired.

Defines the maximum duration between publishing and message reception without considering the message as stale or expired, specified as a positive scalar. Messages that have expired are silently discarded.

The default value is Inf which implies the message can be published and received without being considered as expired, for an infinite duration of time. If Lifespan is set to 5, it means that a message is considered valid for 5 seconds after being published. If subscriber has not received the message within that time frame, the message is considered expired.

Defines the reporting level that the publishers will offer to notify the subscribers that they are alive, specified as a string.

Liveliness QoS policy set to "automatic" implies that a publisher is active for an additional Lease Duration when it publishes a message within that time frame.

Defines the maximum duration allowed to a publisher to demonstrate its liveliness before the system considers it to have lost liveliness, specified as a positive scalar. Losing liveliness could serve as an indication of failure.

The default value is Inf which implies that publisher can assert its liveliness for infinite duration of time. If the Lease Duration is set to 5, it implies that the publisher has a maximum duration of 5 seconds to demonstrate its liveliness. If the publisher does not send any messages or explicitly assert its liveliness within that time frame, it is considered to have lost liveliness.

Extended Capabilities

expand all

C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.

Version History

Introduced in R2019b

expand all

See Also

|