View Source Rclex.QoS (Rclex v0.11.2)
Documentation for Elixir.Rclex.QoS.
See also Quality of Service settings on ROS 2 Documentation.
Summary
Functions
Default QoS settings for publishers and subscriptions
Parameters in ROS 2 are based on services, and as such have a similar profile. The difference is that parameters use a much larger queue depth so that requests do not get lost when, for example, the parameter client is unable to reach the parameter service server
For sensor data, in most cases it’s more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some. For that reason the sensor data profile uses best effort reliability and a smaller queue size.
In the same vein as publishers and subscriptions, services are reliable. It is especially important for services to use volatile durability, as otherwise service servers that re-start may receive outdated requests. While the client is protected from receiving multiple responses, the server is not protected from side-effects of receiving the outdated requests.
This uses the RMW implementation’s default values for all of the policies. Different RMW implementations may have different defaults.
Types
@type t() :: %Rclex.QoS{ avoid_ros_namespace_conventions: boolean(), deadline: float(), depth: non_neg_integer(), durability: :system_default | :transient_local | :volatile, history: :system_default | :keep_last | :keep_all, lifespan: float(), liveliness: :system_default | :automatic | :manual_by_topic, liveliness_lease_duration: float(), reliability: :system_default | :reliable | :best_effort }
deadline,lifespan,liveliness_lease_durationshould be specified by float seconds.
Functions
@spec profile_default() :: t()
Default QoS settings for publishers and subscriptions
@spec profile_parameters() :: t()
Parameters in ROS 2 are based on services, and as such have a similar profile. The difference is that parameters use a much larger queue depth so that requests do not get lost when, for example, the parameter client is unable to reach the parameter service server
@spec profile_sensor_data() :: t()
For sensor data, in most cases it’s more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some. For that reason the sensor data profile uses best effort reliability and a smaller queue size.
@spec profile_services_default() :: t()
In the same vein as publishers and subscriptions, services are reliable. It is especially important for services to use volatile durability, as otherwise service servers that re-start may receive outdated requests. While the client is protected from receiving multiple responses, the server is not protected from side-effects of receiving the outdated requests.
@spec profile_system_default() :: t()
This uses the RMW implementation’s default values for all of the policies. Different RMW implementations may have different defaults.