Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Which profile to use and when.

Resources

Usage

Recommended

qos_profile_sensor_data: use if you don’t care about dropping the odd message (best effort)

qos_profile_services_default: use for services when you care about getting your responses (reliable)

qos_profile_parameters / qos_profile_parameters_events / qos_profile_action_status_default: unknown, haven’t tried these yet, but presumably suit most cases

Latched Topics

Nothing exists out of the box, you’ll want to set up something like:

def qos_profile_latched():
    return rclpy.qos.QoSProfile(
        history=rclpy.qos.QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_LAST,
        depth=1,
        durability=rclpy.qos.QoSDurabilityPolicy.RMW_QOS_POLICY_DURABILITY_TRANSIENT_LOCAL,
        reliability=rclpy.qos.QoSReliabilityPolicy.RMW_QOS_POLICY_RELIABILITY_RELIABLE
    )

Do not Use

qos_profile_default: this one exists in rclcpp, but it is recommended not to use it, one should think more deeply about the profile being set (see rclpy/qos.py#L33 where they mention exactly this and intentionally hide the default).

qos_profile_system_default: use the underlying dds implementation’s default

  • No labels