The TracingId is used as a wrapper for the pointer to allow implementing
Send and Sync traits.
The pointer is used only as an ID and is never dereferenced, therefore, it is safe.
The crate contains tracepoints; either defined directly or imported
from ros2_tracing project (tracetools package).
The crate define a `tracing` feature which should only be used on Linux
because it uses LTTng only available on Linux.
This change is necessary because rcl uses address of the rcl handle in
tracepoints. If the location changes further `take` events will not
be correctly assigned to the subscriber.
This change is necessary because rcl uses address of the rcl handle in
tracepoints. If the location changes, further publish events will not
be correctly assigned to the publisher.
* Fixed failing `ros2 param ...` on r2r nodes for Jazzy (#120)
Add `/set_parameters_atomically` service to `make_parameter_handler_internal` in `nodes.rs` to fix failing `ros2 param ...` on r2r nodes for Jazzy.
* Atomic behavior for `set_parameters_atomically` (#121).
---------
Co-authored-by: Desmond Germans <desmond@germansmedia.nl>
* Implement TryInto for ParameterValue
* Add `get_parameter` method.
* Consolidate 'ParameterNotSet' into 'ParamterWrongType' error
* Add support for optional parameters
* Add example for get_parameter.
This fixes undefined behaviour, as the
rcl_subscription_get_topic_name documentation
states that the topic is no longer valid when
the subscription dies
Adds a QosProfile parameter for `Node::create_client` and `Node::node.create_service`.
`QosProfile::default()` can be passed when updating existing code.
The previous commit made the order of parameters deterministic
(defined by so called insertion order), but the order still depends on
whether or not some parameters were set from the command line. Command
line parameters are inserted to the IndexMap at Node creation time,
while other RosParams-derived parameters later, during the call to
make_derived_parameter_handler().
This commit ensures that parameters processed by
make_derived_parameter_handler() are always inserted in the same
order, even if some of them were already inserted before due to CLI
arguments.
GUI tools for working with parameters (at least Foxglove Studio, rqt
and rig_reconfigure) show the parameters in the same order as returned
by the ListParameters service. r2r stores the parameters in a HashMap,
which iterates keys and values in arbitrary order. The result is that
the GUI tools show the parameters in different order after every node
invocation, which can be quite annoying.
To make the order deterministic, we change the parameter storage from
HashMap to IndexMap, which iterates the map in insertion order.
According to the indexmap documentation, IndexMap is a drop-in
replacement of HashMap so this change should not require code changes
in applications using r2r. At least r2r examples and my projects
needed no changes.
cfg(r2r__rosgraph_msgs__msg__Clock) attribute is not propagated to user
code so this macro can be used to intentionally fail compilation if
sim time is not supported.